Re: [PATCH v5 10/33] iommu, irq: Allocate irq_desc for dmar_msi with local node
On Fri, Feb 21, 2014 at 7:14 PM, Jiang Liu wrote:
> Seems there is no such protection on IA64 side. I feel create_irq_nr()
> returns 0 for error is a little risky, 0 may be
> a valid IRQ number on other platforms(no sure about this).
> Thanks!
in [PATCH] ia64, irq: Add dummy create_irq_nr()
+unsigned int create_irq_nr(unsigned int from, int node)
+{
+ int irq = create_irq();
+
+ if (irq < 0)
+ irq = 0;
+
+ return irq;
+}
+
so that from is ignored.
create_irq_nr() is only with x86 and ia64.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] affs: Add __init to init_inodecache ()
init_inodecache is only called by __init init_affs_fs
Signed-off-by: Fabian Frederick
---
fs/affs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/affs/super.c b/fs/affs/super.c
index d098731..41a7557 100644
--- a/fs/affs/super.c
+++ b/fs/affs/super.c
@@ -128,7 +128,7 @@ static void init_once(void *foo)
inode_init_once(>vfs_inode);
}
-static int init_inodecache(void)
+static int __init init_inodecache(void)
{
affs_inode_cachep = kmem_cache_create("affs_inode_cache",
sizeof(struct affs_inode_info),
--
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 v7 8/8] ARM: sunxi: Add documentation for driver for SD/MMC hosts found on Allwinner sunxi SoCs
Hi > Please use the real compatibles here. It's much easier to search > for. Plus, your driver doesn't support all the SoCs you're mentionning here. > [...] > Please provide the real property name to use. No need for an example > here, you have a full-fledged one in a few lines. Fixed that. > Ditto. Plus, this is not a mod0 clock. Yes it is! But maybe the formulation hasn't been clear enough... > You never talked about the clock-names property, and which clocks were > supposed to be provided. Yes I did? But I expanded the text a little bit further... > > + interrupts = <0 32 4>; > > + bus-width = <4>; > And you never talked about bus-width either. I can throw in a line for refering to the mmc slot gpio lib docs. > Isn't the cd-gpios property requested too? I can refer to the docs there as well if you like... :-) cheers david signature.asc Description: This is a digitally signed message part.
[PATCH 3/4] w1: mxc_w1: Driver cleanup
- Remove old and currently wrong address of the FSF from license
parts of the code.
- Remove unused #include and sort remaining headers alphabetically.
- Remove unised definitions.
- Add definitions for bit-fields.
- Add missing module owner field.
Signed-off-by: Alexander Shiyan
---
drivers/w1/masters/mxc_w1.c | 39 ---
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 6525b2c..8e3de6a 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -10,24 +10,16 @@
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
- *
*/
-#include
-#include
-#include
#include
-#include
#include
#include
+#include
+#include
#include "../w1.h"
#include "../w1_int.h"
-#include "../w1_log.h"
/* According to the mx27 Datasheet the reset procedure should take up to about
* 1350us. We set the timeout to 500*100us = 50ms for sure */
@@ -36,13 +28,13 @@
/*
* MXC W1 Register offsets
*/
-#define MXC_W1_CONTROL 0x00
-#define MXC_W1_TIME_DIVIDER 0x02
-#define MXC_W1_RESET0x04
-#define MXC_W1_COMMAND 0x06
-#define MXC_W1_TXRX 0x08
-#define MXC_W1_INTERRUPT0x0A
-#define MXC_W1_INTERRUPT_EN 0x0C
+#define MXC_W1_CONTROL 0x00
+# define MXC_W1_CONTROL_RDST BIT(3)
+# define MXC_W1_CONTROL_WR(x) BIT(5 - (x))
+# define MXC_W1_CONTROL_PSTBIT(6)
+# define MXC_W1_CONTROL_RPPBIT(7)
+#define MXC_W1_TIME_DIVIDER0x02
+#define MXC_W1_RESET 0x04
struct mxc_w1_device {
void __iomem *regs;
@@ -61,12 +53,12 @@ static u8 mxc_w1_ds2_reset_bus(void *data)
unsigned int timeout_cnt = 0;
struct mxc_w1_device *dev = data;
- __raw_writeb(0x80, (dev->regs + MXC_W1_CONTROL));
+ __raw_writeb(MXC_W1_CONTROL_RPP, (dev->regs + MXC_W1_CONTROL));
while (1) {
reg_val = __raw_readb(dev->regs + MXC_W1_CONTROL);
- if (((reg_val >> 7) & 0x1) == 0 ||
+ if (!(reg_val & MXC_W1_CONTROL_RPP) ||
timeout_cnt > MXC_W1_RESET_TIMEOUT)
break;
else
@@ -74,7 +66,7 @@ static u8 mxc_w1_ds2_reset_bus(void *data)
udelay(100);
}
- return (reg_val >> 6) & 0x1;
+ return !!(reg_val & MXC_W1_CONTROL_PST);
}
/*
@@ -90,16 +82,16 @@ static u8 mxc_w1_ds2_touch_bit(void *data, u8 bit)
* datasheet.
*/
- __raw_writeb((1 << (5 - bit)), ctrl_addr);
+ __raw_writeb(MXC_W1_CONTROL_WR(bit), ctrl_addr);
while (timeout_cnt--) {
- if (!((__raw_readb(ctrl_addr) >> (5 - bit)) & 0x1))
+ if (!(__raw_readb(ctrl_addr) & MXC_W1_CONTROL_WR(bit)))
break;
udelay(1);
}
- return ((__raw_readb(ctrl_addr)) >> 3) & 0x1;
+ return !!(__raw_readb(ctrl_addr) & MXC_W1_CONTROL_RDST);
}
static int mxc_w1_probe(struct platform_device *pdev)
@@ -177,6 +169,7 @@ MODULE_DEVICE_TABLE(of, mxc_w1_dt_ids);
static struct platform_driver mxc_w1_driver = {
.driver = {
.name = "mxc_w1",
+ .owner = THIS_MODULE,
.of_match_table = mxc_w1_dt_ids,
},
.probe = mxc_w1_probe,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] w1: Remove excess dependencies on W1 for masters and slaves
Configuration for masters and slaves is included only if W1 symbol enabled, so no reason to check it once more. Signed-off-by: Alexander Shiyan --- drivers/w1/masters/Kconfig | 3 +-- drivers/w1/slaves/Kconfig | 5 - 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig index efc7f07..6ffe120 100644 --- a/drivers/w1/masters/Kconfig +++ b/drivers/w1/masters/Kconfig @@ -36,13 +36,12 @@ config W1_MASTER_DS2482 config W1_MASTER_MXC tristate "Freescale MXC 1-wire busmaster" - depends on W1 && ARCH_MXC + depends on ARCH_MXC help Say Y here to enable MXC 1-wire host config W1_MASTER_DS1WM tristate "Maxim DS1WM 1-wire busmaster" - depends on W1 help Say Y here to enable the DS1WM 1-wire driver, such as that in HP iPAQ devices like h5xxx, h2200, and ASIC3-based like diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig index 5e6a3c9..1cdce80 100644 --- a/drivers/w1/slaves/Kconfig +++ b/drivers/w1/slaves/Kconfig @@ -72,7 +72,6 @@ config W1_SLAVE_DS2433_CRC config W1_SLAVE_DS2760 tristate "Dallas 2760 battery monitor chip (HP iPAQ & others)" - depends on W1 help If you enable this you will have the DS2760 battery monitor chip support. @@ -85,7 +84,6 @@ config W1_SLAVE_DS2760 config W1_SLAVE_DS2780 tristate "Dallas 2780 battery monitor chip" - depends on W1 help If you enable this you will have the DS2780 battery monitor chip support. @@ -98,7 +96,6 @@ config W1_SLAVE_DS2780 config W1_SLAVE_DS2781 tristate "Dallas 2781 battery monitor chip" - depends on W1 help If you enable this you will have the DS2781 battery monitor chip support. @@ -111,7 +108,6 @@ config W1_SLAVE_DS2781 config W1_SLAVE_DS28E04 tristate "4096-Bit Addressable 1-Wire EEPROM with PIO (DS28E04-100)" - depends on W1 select CRC16 help If you enable this you will have the DS28E04-100 @@ -124,7 +120,6 @@ config W1_SLAVE_DS28E04 config W1_SLAVE_BQ27000 tristate "BQ27000 slave support" - depends on W1 help Say Y here if you want to use a hdq bq27000 slave support. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] w1: mxc_w1: Enable driver compilation with COMPILE_TEST
This helps increasing build testing coverage.
To do this, __raw_{read,write}b() functions was be replaced with
simple {read,write}b() variants.
Signed-off-by: Alexander Shiyan
---
drivers/w1/masters/Kconfig | 2 +-
drivers/w1/masters/mxc_w1.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig
index 6ffe120..1708b23 100644
--- a/drivers/w1/masters/Kconfig
+++ b/drivers/w1/masters/Kconfig
@@ -36,7 +36,7 @@ config W1_MASTER_DS2482
config W1_MASTER_MXC
tristate "Freescale MXC 1-wire busmaster"
- depends on ARCH_MXC
+ depends on ARCH_MXC || COMPILE_TEST
help
Say Y here to enable MXC 1-wire host
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 8e3de6a..67b067a 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -53,10 +53,10 @@ static u8 mxc_w1_ds2_reset_bus(void *data)
unsigned int timeout_cnt = 0;
struct mxc_w1_device *dev = data;
- __raw_writeb(MXC_W1_CONTROL_RPP, (dev->regs + MXC_W1_CONTROL));
+ writeb(MXC_W1_CONTROL_RPP, (dev->regs + MXC_W1_CONTROL));
while (1) {
- reg_val = __raw_readb(dev->regs + MXC_W1_CONTROL);
+ reg_val = readb(dev->regs + MXC_W1_CONTROL);
if (!(reg_val & MXC_W1_CONTROL_RPP) ||
timeout_cnt > MXC_W1_RESET_TIMEOUT)
@@ -82,16 +82,16 @@ static u8 mxc_w1_ds2_touch_bit(void *data, u8 bit)
* datasheet.
*/
- __raw_writeb(MXC_W1_CONTROL_WR(bit), ctrl_addr);
+ writeb(MXC_W1_CONTROL_WR(bit), ctrl_addr);
while (timeout_cnt--) {
- if (!(__raw_readb(ctrl_addr) & MXC_W1_CONTROL_WR(bit)))
+ if (!(readb(ctrl_addr) & MXC_W1_CONTROL_WR(bit)))
break;
udelay(1);
}
- return !!(__raw_readb(ctrl_addr) & MXC_W1_CONTROL_RDST);
+ return !!(readb(ctrl_addr) & MXC_W1_CONTROL_RDST);
}
static int mxc_w1_probe(struct platform_device *pdev)
@@ -131,7 +131,7 @@ static int mxc_w1_probe(struct platform_device *pdev)
if (err)
return err;
- __raw_writeb(clkdiv - 1, mdev->regs + MXC_W1_TIME_DIVIDER);
+ writeb(clkdiv - 1, mdev->regs + MXC_W1_TIME_DIVIDER);
mdev->bus_master.data = mdev;
mdev->bus_master.reset_bus = mxc_w1_ds2_reset_bus;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] w1: mxc_w1: Fix mxc_w1_ds2_reset_bus() return value
This patch fix mxc_w1_ds2_reset_bus() return value. According to i.MX reference manual, "presence status" reflected in the bit 6 of control register. Signed-off-by: Alexander Shiyan --- drivers/w1/masters/mxc_w1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c index 1e5d94c..6525b2c 100644 --- a/drivers/w1/masters/mxc_w1.c +++ b/drivers/w1/masters/mxc_w1.c @@ -74,7 +74,7 @@ static u8 mxc_w1_ds2_reset_bus(void *data) udelay(100); } - return (reg_val >> 7) & 0x1; + return (reg_val >> 6) & 0x1; } /* -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Interested In Your Products
Hello I am from GEA Groups Company Ltd, we are really interested in your product being advertise in IM. We would like to have quotations for the following products. Kindly log on to our website by clicking on the link below to view the sample of the products we wish to buy. http://productz.concrete5.arvixe.com/marketing/product/myproducts.html Thanks & Best regards, Liu Lee Purchasing Manager -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v1 3/3] ARM hibernation / suspend-to-disk
On 02/21/2014 08:37 PM, Sebastian Capella wrote: > Quoting Sebastian Capella (2014-02-21 15:59:11) >> - Cyril Chemparathy as his email is bouncing back to me. >> >> Quoting Sebastian Capella (2014-02-21 10:39:56) >>> Quoting Lorenzo Pieralisi (2014-02-20 08:27:55) >>> + cpu_switch_mm(idmap_pgd, _mm); >> [ ... ] >>> I can try removing it and seeing if there are side effects. >> >> FYI, It's definitely hanging with this removed, still looking. > > I see when we reach this call, the 1st level page table @ TTBR0 is located > at different memory locations each run (expected). If we omit the > cpu_switch_mm we're corrupting the page table causing the observed > intermittent failures. I believe these match the corruption you expected. > > The reason this doesn't happen when I leave the call is that idmap_pgd > is always at the same memory location. I expect this is because it's > allocated during init. I've seen the same address 50/50 times for > idmap_pgd. I don't think it is correct to rely on this behavior. > > Would it be appropriate to use the swapper_pg_dir directly in place > of idmap_pgd? > - I do not see any modification to the swapper_pg_dir contents in the > code that would change from init time. > - swapper_pg_dir is always at the same offset. > > Ideally we should have no issue with overwriting it with identical data. > > I've run a couple hundred test loops using swapper_pg_dir and so far > there are no failures. If there is worry about this, you could setup a page mapping in a __nosave region, preventing it from being overwritten. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] irqchip: armada-370-xp changes for v3.15
Thomas, This is a small round of changes intended for v3.15. Despite the commit date these have been in -next for almost a week. I needed to rebase the branch on v3.14-rc1 instead of merging it. When I originally added these patches, the dove PMU hadn't been pulled from this branch yet. At any rate, these patches depend on the tag mvebu-irqchip-fixes-3.13 which you've already pulled in. They need the MSI fix from that series. Please pull. thx, Jason. The following changes since commit 3efca1d15656fe7e3f57c1f5f21e596967355200: Merge tag 'tags/mvebu-irqchip-fixes-3.13' into mvebu/irqchip (2014-02-22 06:11:45 +) are available in the git repository at: git://git.infradead.org/linux-mvebu.git tags/irqchip-mvebu-3.15 for you to fetch changes up to bc69b8adfe221def02ea10f7b9ab32e80195334c: irqchip: armada-370-xp: Setup a chained handler for the MPIC (2014-02-22 06:12:29 +) irqchip mvebu changes for v3.15 - armada-370-xp - add MSI helper - MPIC chained handler Ezequiel Garcia (2): irqchip: armada-370-xp: Add helper for the MSI IRQ handling irqchip: armada-370-xp: Setup a chained handler for the MPIC .../devicetree/bindings/arm/armada-370-xp-mpic.txt | 8 +- drivers/irqchip/irq-armada-370-xp.c| 96 -- 2 files changed, 76 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf_fuzzer compiled for x32 causes reboot
On 02/21/2014 08:50 PM, Vince Weaver wrote: So I changed the perf_fuzzer so when it randomly stomps all over the perf_event_mmap_page, it uses a constant value of 0xdeadbeef rather than a random value. The result is below. The segfaults make a bit more sense now, it almost looks like what is happening is we are corrupting an address value somehow (head? tail?) and the kernel then uses the corrupt address and writes to memory outside of the mmap ring buffer. That seems unlikely: handle->page = (offset >> page_shift) & (rb->nr_pages - 1); offset &= (1UL << page_shift) - 1; The masking to the number of pages should make that not possible, even if a completely bogus value is written. I still haven't figured out how to trigger this exactly, but you can see when over-written with 0xdeadbeef the memory address written to is consistently some small multiple of 0x120. I imagine it would be a bad thing if it turned out to be possible to select what memory address got written to. Although since I've only reproduced this on x32 maybe it won't be possible to over-write the kernel; but I have seen this bug cause a reboot when the wrong thing got over-written. [28002.850192] perf_fuzzer[7083]: segfault at 2be0 ip 0041efab sp ff826748 error 6 in perf_fuzzer[40+d1000] [28639.769869] perf_fuzzer[7100]: segfault at 1320 ip 0041efab sp ffa65038 error 6 in perf_fuzzer[40+d1000] [29396.986242] perf_fuzzer[7120]: segfault at 10e0 ip 0041efab sp ffd48e68 error 6 in perf_fuzzer[40+d1000] [29738.892931] perf_fuzzer[7128]: segfault at 18c0 ip 0041efab sp ffcdcd88 error 6 in perf_fuzzer[40+d1000] [29815.550210] perf_fuzzer[7132]: segfault at 120 ip 0041efab sp ffe673b8 error 6 in perf_fuzzer[40+d1000] [30173.455348] perf_fuzzer[7141]: segfault at 120 ip 0041efab sp ffda1948 error 6 in perf_fuzzer[40+d1000] [30570.625642] perf_fuzzer[7156]: segfault at 1680 ip 0041efab sp ffaad028 error 6 in perf_fuzzer[40+d1000] [31047.887784] perf_fuzzer[7169]: segfault at 60c0 ip 0041efab sp ffaa86e8 error 6 in perf_fuzzer[40+d1000] [31300.168714] perf_fuzzer[7175]: segfault at 3a80 ip 0041efab sp ffd83228 error 6 in perf_fuzzer[40+d1000] [31984.727278] perf_fuzzer[7193]: segfault at 7e0 ip 0041efab sp ff9db1f8 error 6 in perf_fuzzer[40+d1000] Error 6 reflects a write in userspace to a not-present page. Since your previous trace indicates that the value of the register in question is a different one, I'm guessing that what we have here is PEBS getting activated. 0x120 is 2*0x90, and 0x90 is the size of a 64-bit PEBS record. -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/
[PATCH] mfd: syscon: Move diagnostic messages to dev_dbg()
This patch moves diagnostic messages used for debugging purposes to dev_dbg(). Signed-off-by: Alexander Shiyan --- drivers/mfd/syscon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index 71841f9..2620056 100644 --- a/drivers/mfd/syscon.c +++ b/drivers/mfd/syscon.c @@ -152,7 +152,7 @@ static int syscon_probe(struct platform_device *pdev) platform_set_drvdata(pdev, syscon); - dev_info(dev, "regmap %pR registered\n", res); + dev_dbg(dev, "regmap %pR registered\n", res); return 0; } -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf_fuzzer compiled for x32 causes reboot
Those are segfaults in user space, though? On February 21, 2014 8:50:38 PM PST, Vince Weaver wrote: > >So I changed the perf_fuzzer so when it randomly stomps all over the >perf_event_mmap_page, it uses a constant value of 0xdeadbeef rather >than a random value. > >The result is below. The segfaults make a bit more sense now, it >almost looks like what is happening is we are corrupting an address >value somehow (head? tail?) and the kernel then uses the corrupt >address >and writes to memory outside of the mmap ring buffer. > >I still haven't figured out how to trigger this exactly, but you can >see when over-written with 0xdeadbeef the memory address written to is >consistently some small multiple of 0x120. > >I imagine it would be a bad thing if it turned out to be possible to >select what memory address got written to. Although since I've >only reproduced this on x32 maybe it won't be possible to over-write >the kernel; but I have seen this bug cause a reboot when the >wrong thing got over-written. > >[28002.850192] perf_fuzzer[7083]: segfault at 2be0 ip 0041efab >sp ff826748 error 6 in perf_fuzzer[40+d1000] >[28639.769869] perf_fuzzer[7100]: segfault at 1320 ip 0041efab >sp ffa65038 error 6 in perf_fuzzer[40+d1000] >[29396.986242] perf_fuzzer[7120]: segfault at 10e0 ip 0041efab >sp ffd48e68 error 6 in perf_fuzzer[40+d1000] >[29738.892931] perf_fuzzer[7128]: segfault at 18c0 ip 0041efab >sp ffcdcd88 error 6 in perf_fuzzer[40+d1000] >[29815.550210] perf_fuzzer[7132]: segfault at 120 ip 0041efab >sp ffe673b8 error 6 in perf_fuzzer[40+d1000] >[30173.455348] perf_fuzzer[7141]: segfault at 120 ip 0041efab >sp ffda1948 error 6 in perf_fuzzer[40+d1000] >[30570.625642] perf_fuzzer[7156]: segfault at 1680 ip 0041efab >sp ffaad028 error 6 in perf_fuzzer[40+d1000] >[31047.887784] perf_fuzzer[7169]: segfault at 60c0 ip 0041efab >sp ffaa86e8 error 6 in perf_fuzzer[40+d1000] >[31300.168714] perf_fuzzer[7175]: segfault at 3a80 ip 0041efab >sp ffd83228 error 6 in perf_fuzzer[40+d1000] >[31984.727278] perf_fuzzer[7193]: segfault at 7e0 ip 0041efab >sp ff9db1f8 error 6 in perf_fuzzer[40+d1000] > >Vince -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: per-thread vma caching
On Fri, 2014-02-21 at 20:55 -0800, Davidlohr Bueso wrote: > On Fri, 2014-02-21 at 13:24 -0800, Linus Torvalds wrote: > > On Fri, Feb 21, 2014 at 12:57 PM, Davidlohr Bueso wrote: > > > > > > Btw, one concern I had is regarding seqnum overflows... if such > > > scenarios should happen we'd end up potentially returning bogus vmas and > > > getting bus errors and other sorts of issues. So we'd have to flush the > > > caches, but, do we care? I guess on 32bit systems it could be a bit more > > > possible to trigger given enough forking. > > > > I guess we should do something like > > > > if (unlikely(!++seqnum)) > > flush_vma_cache() > > > > just to not have to worry about it. > > > > And we can either use a "#ifndef CONFIG_64BIT" to disable it for the > > 64-bit case (because no, we really don't need to worry about overflow > > in 64 bits ;), or just decide that a 32-bit sequence number actually > > packs better in the structures, and make it be an "u32" even on 64-bit > > architectures? > > > > It looks like a 32-bit sequence number might pack nicely next to the > > > > unsigned brk_randomized:1; > > And probably specially so for structures like task and mm. I hadn't > considered the benefits of packing vs overflowing. So we can afford > flushing all tasks's vmacache every 4 billion forks. ah, not quite that much, I was just thinking of dup_mmap, of course we also increment upon invalidations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: per-thread vma caching
On Fri, 2014-02-21 at 13:24 -0800, Linus Torvalds wrote: > On Fri, Feb 21, 2014 at 12:57 PM, Davidlohr Bueso wrote: > > > > Btw, one concern I had is regarding seqnum overflows... if such > > scenarios should happen we'd end up potentially returning bogus vmas and > > getting bus errors and other sorts of issues. So we'd have to flush the > > caches, but, do we care? I guess on 32bit systems it could be a bit more > > possible to trigger given enough forking. > > I guess we should do something like > > if (unlikely(!++seqnum)) > flush_vma_cache() > > just to not have to worry about it. > > And we can either use a "#ifndef CONFIG_64BIT" to disable it for the > 64-bit case (because no, we really don't need to worry about overflow > in 64 bits ;), or just decide that a 32-bit sequence number actually > packs better in the structures, and make it be an "u32" even on 64-bit > architectures? > > It looks like a 32-bit sequence number might pack nicely next to the > > unsigned brk_randomized:1; And probably specially so for structures like task and mm. I hadn't considered the benefits of packing vs overflowing. So we can afford flushing all tasks's vmacache every 4 billion forks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC] regulator: anatop: Remove checking control_reg in [set|get]_voltage_sel
Remove checking control_reg in [set|get]_voltage_sel and then convert to use
regulator_[set|get]_voltage_sel_regmap for [set|get]_voltage_sel callbacks.
The anatop-reg-offset property is a required property rather than optional
property. So the question is what is the meaning of setting anatop-reg-offset
to 0? If 0 is a valid setting for anatop-reg-offset and it has special meaning,
we had better document it in the binding document. Otherwise, remove the testing
for control_reg in the driver.
No anatop voltage regulator node in the dts files set anatop-reg-offset to 0.
So I think it's safe to remove testing if control_reg is 0.
Signed-off-by: Axel Lin
---
drivers/regulator/anatop-regulator.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 38e8122..7c397bb 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -55,17 +55,6 @@ struct anatop_regulator {
int sel;
};
-static int anatop_regmap_set_voltage_sel(struct regulator_dev *reg,
- unsigned selector)
-{
- struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
-
- if (!anatop_reg->control_reg)
- return -ENOTSUPP;
-
- return regulator_set_voltage_sel_regmap(reg, selector);
-}
-
static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
unsigned int old_sel,
unsigned int new_sel)
@@ -92,16 +81,6 @@ static int anatop_regmap_set_voltage_time_sel(struct
regulator_dev *reg,
return ret;
}
-static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
-{
- struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
-
- if (!anatop_reg->control_reg)
- return -ENOTSUPP;
-
- return regulator_get_voltage_sel_regmap(reg);
-}
-
static int anatop_regmap_enable(struct regulator_dev *reg)
{
struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
@@ -178,8 +157,8 @@ static int anatop_regmap_set_bypass(struct regulator_dev
*reg, bool enable)
}
static struct regulator_ops anatop_rops = {
- .set_voltage_sel = anatop_regmap_set_voltage_sel,
- .get_voltage_sel = anatop_regmap_get_voltage_sel,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf_fuzzer compiled for x32 causes reboot
So I changed the perf_fuzzer so when it randomly stomps all over the perf_event_mmap_page, it uses a constant value of 0xdeadbeef rather than a random value. The result is below. The segfaults make a bit more sense now, it almost looks like what is happening is we are corrupting an address value somehow (head? tail?) and the kernel then uses the corrupt address and writes to memory outside of the mmap ring buffer. I still haven't figured out how to trigger this exactly, but you can see when over-written with 0xdeadbeef the memory address written to is consistently some small multiple of 0x120. I imagine it would be a bad thing if it turned out to be possible to select what memory address got written to. Although since I've only reproduced this on x32 maybe it won't be possible to over-write the kernel; but I have seen this bug cause a reboot when the wrong thing got over-written. [28002.850192] perf_fuzzer[7083]: segfault at 2be0 ip 0041efab sp ff826748 error 6 in perf_fuzzer[40+d1000] [28639.769869] perf_fuzzer[7100]: segfault at 1320 ip 0041efab sp ffa65038 error 6 in perf_fuzzer[40+d1000] [29396.986242] perf_fuzzer[7120]: segfault at 10e0 ip 0041efab sp ffd48e68 error 6 in perf_fuzzer[40+d1000] [29738.892931] perf_fuzzer[7128]: segfault at 18c0 ip 0041efab sp ffcdcd88 error 6 in perf_fuzzer[40+d1000] [29815.550210] perf_fuzzer[7132]: segfault at 120 ip 0041efab sp ffe673b8 error 6 in perf_fuzzer[40+d1000] [30173.455348] perf_fuzzer[7141]: segfault at 120 ip 0041efab sp ffda1948 error 6 in perf_fuzzer[40+d1000] [30570.625642] perf_fuzzer[7156]: segfault at 1680 ip 0041efab sp ffaad028 error 6 in perf_fuzzer[40+d1000] [31047.887784] perf_fuzzer[7169]: segfault at 60c0 ip 0041efab sp ffaa86e8 error 6 in perf_fuzzer[40+d1000] [31300.168714] perf_fuzzer[7175]: segfault at 3a80 ip 0041efab sp ffd83228 error 6 in perf_fuzzer[40+d1000] [31984.727278] perf_fuzzer[7193]: segfault at 7e0 ip 0041efab sp ff9db1f8 error 6 in perf_fuzzer[40+d1000] Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] hugetlb: add hugepages_node= command-line option
On Sat, 22 Feb 2014 05:03:50 +0100 Andi Kleen wrote: > > But I think it would be better if it made hugepages= and hugepagesz= > > obsolete, so we can emit a printk if people use those, telling them > > to migrate because the old options are going away. > > Not sure why everyone wants to break existing systems. These options > have existed for many years, you cannot not just remove them. Because we care about the quality of kernel interfaces and implementation. Five years? We'll still be around then. > Also the old options are totally fine and work adequately for the > vast majority of users who do not need to control node assignment > fine grained. It will be old, unneeded cruft. Don't accumulate cruft. If we possibly can remove the old stuff, we should. It's what we do. Maybe in five years we'll find we can't remove them. We'll see. At least we tried. Hopefully by then none of these interfaces will be in use 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/
Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option
On Sat, 2014-02-22 at 05:03 +0100, Andi Kleen wrote: > > But I think it would be better if it made hugepages= and hugepagesz= > > obsolete, so we can emit a printk if people use those, telling them > > to migrate because the old options are going away. > > Not sure why everyone wants to break existing systems. These options > have existed for many years, you cannot not just remove them. > > Also the old options are totally fine and work adequately for the > vast majority of users who do not need to control node assignment > fine grained. Yes, please, why can't both options just coexist. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] hugetlb: add hugepages_node= command-line option
> But I think it would be better if it made hugepages= and hugepagesz= > obsolete, so we can emit a printk if people use those, telling them > to migrate because the old options are going away. Not sure why everyone wants to break existing systems. These options have existed for many years, you cannot not just remove them. Also the old options are totally fine and work adequately for the vast majority of users who do not need to control node assignment fine grained. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] hwmon fixes for 3.14-rc4
Hi Linus, Please pull hwmon fixes for Linux 3.14-rc4 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus Thanks, Guenter -- The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus for you to fetch changes up to 500a91571f0a5d0d3242d83802ea2fd1faccc66e: hwmon: (max1668) Fix writing the minimum temperature (2014-02-18 15:53:49 -0800) Fix writing the minimum temperature in max1668 driver. Guenter Roeck (1): hwmon: (max1668) Fix writing the minimum temperature drivers/hwmon/max1668.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) signature.asc Description: Digital signature
[PATCH 3/3] Staging: comedi: addi-data: fix a couple of lines that are too long
There are a couple of cases where a comment being on the same line as a
statement is causing the line to be over 80 characters long. This is an
easy fix; move these comments to the previous line.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 34e5321..d5c4e71 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -565,7 +565,9 @@ static int i_APCI035_Reset(struct comedi_device *dev)
for (i_Count = 1; i_Count <= 4; i_Count++) {
i_WatchdogNbr = i_Count;
- outl(0x0, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 0);
/* stop all timers */
+
+ /* stop all timers */
+ outl(0x0, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 0);
}
outl(0x0, devpriv->iobase + 128 + 12); /* Disable the warning delay */
@@ -624,11 +626,14 @@ static void v_APCI035_Interrupt(int irq, void *d)
/* Read the digital temperature value */
ui_DigitalTemperature = inl(devpriv->iobase + 128 + 60);
- send_sig(SIGIO, devpriv->tsk_Current, 0); /* send signal
to the sample */
+
+ /* send signal to the sample */
+ send_sig(SIGIO, devpriv->tsk_Current, 0);
}
else if ((ui_StatusRegister2 & 0x1) == 0x1)
- send_sig(SIGIO, devpriv->tsk_Current, 0); /* send signal
to the sample */
+ /* send signal to the sample */
+ send_sig(SIGIO, devpriv->tsk_Current, 0);
return;
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] Staging: comedi: addi-data: cleanup conditional blocks in hwdrv_apci035.c
There were some conditional blocks that had an unneccesary level of
indentation in them. We can remove this to improve code clarity.
Signed-off-by: Chase Southwood
---
.../comedi/drivers/addi-data/hwdrv_apci035.c | 31 ++
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 7c40535..34e5321 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -207,23 +207,22 @@ static int i_APCI035_ConfigTimerWatchdog(struct
comedi_device *dev,
ui_Command =
(ui_Command & 0xFFF719E2UL) | ui_Mode << 13UL | 0x10UL;
- } else {
- if (data[0] == ADDIDATA_WATCHDOG) {
+ } else if (data[0] == ADDIDATA_WATCHDOG) {
- /* Set the mode : */
- /* - Disable the hardware */
- /* - Disable the counter mode */
- /* - Disable the warning */
- /* - Disable the reset*/
- /* - Disable the timer mode */
+ /* Set the mode : */
+ /* - Disable the hardware */
+ /* - Disable the counter mode */
+ /* - Disable the warning */
+ /* - Disable the reset*/
+ /* - Disable the timer mode */
- ui_Command = ui_Command & 0xFFF819E2UL;
+ ui_Command = ui_Command & 0xFFF819E2UL;
- } else {
- dev_err(dev->class_dev, "The parameter for
Timer/watchdog selection is in error\n");
- return -EINVAL;
- }
+ } else {
+ dev_err(dev->class_dev, "The parameter for Timer/watchdog
selection is in error\n");
+ return -EINVAL;
}
+
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
@@ -628,10 +627,8 @@ static void v_APCI035_Interrupt(int irq, void *d)
send_sig(SIGIO, devpriv->tsk_Current, 0); /* send signal
to the sample */
}
- else {
- if ((ui_StatusRegister2 & 0x1) == 0x1)
- send_sig(SIGIO, devpriv->tsk_Current, 0); /*
send signal to the sample */
- }
+ else if ((ui_StatusRegister2 & 0x1) == 0x1)
+ send_sig(SIGIO, devpriv->tsk_Current, 0); /* send signal
to the sample */
return;
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] Staging: comedi: addi-data: comment cleanup in hwdrv_apci035.c
This patch further cleans up the comments in hwdrv_apci035.c, converting
them to kernel style and removing some commented conditional statements
that are unused.
Signed-off-by: Chase Southwood
---
I decided to return to the first driver I touched. I found some more
things that could be cleaned up a little.
.../comedi/drivers/addi-data/hwdrv_apci035.c | 106 +++--
1 file changed, 32 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 8ce3335..7c40535 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -188,17 +188,14 @@ static int i_APCI035_ConfigTimerWatchdog(struct
comedi_device *dev,
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
- //
+
/* Set the reload value */
- //
outl(data[3], devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 4);
- /*/
+
/* Set the time unit */
- /*/
outl(data[2], devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 8);
if (data[0] == ADDIDATA_TIMER) {
- /**/
/* Set the mode : */
/* - Disable the hardware */
/* - Disable the counter mode */
@@ -206,23 +203,19 @@ static int i_APCI035_ConfigTimerWatchdog(struct
comedi_device *dev,
/* - Disable the reset*/
/* - Enable the timer mode*/
/* - Set the timer mode */
- /**/
ui_Command =
(ui_Command & 0xFFF719E2UL) | ui_Mode << 13UL | 0x10UL;
- } /* if (data[0] == ADDIDATA_TIMER) */
- else {
+ } else {
if (data[0] == ADDIDATA_WATCHDOG) {
- /**/
/* Set the mode : */
/* - Disable the hardware */
/* - Disable the counter mode */
/* - Disable the warning */
/* - Disable the reset*/
/* - Disable the timer mode */
- /**/
ui_Command = ui_Command & 0xFFF819E2UL;
@@ -234,73 +227,61 @@ static int i_APCI035_ConfigTimerWatchdog(struct
comedi_device *dev,
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
- //
+
/* Disable the hardware trigger */
- //
ui_Command = ui_Command & 0xF89FUL;
if (data[4] == ADDIDATA_ENABLE) {
- /**/
+
/* Set the hardware trigger level */
- /**/
ui_Command = ui_Command | (data[5] << 5);
}
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
- /*/
+
/* Disable the hardware gate */
- /*/
ui_Command = ui_Command & 0xF87FUL;
if (data[6] == ADDIDATA_ENABLE) {
- /***/
+
/* Set the hardware gate level */
- /***/
ui_Command = ui_Command | (data[7] << 7);
}
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
- /***/
+
/* Disable the hardware output */
- /***/
ui_Command = ui_Command & 0xF9FBUL;
- /*/
+
/* Set the hardware output level */
- /*/
ui_Command = ui_Command | (data[8] << 2);
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
if (data[9] == ADDIDATA_ENABLE) {
- //
+
/* Set the reload value */
- //
outl(data[11],
devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 24);
- /**/
+
/* Set the time unite */
-
Re: [PATCH v5 10/33] iommu, irq: Allocate irq_desc for dmar_msi with local node
On 2014/2/22 7:18, Yinghai Lu wrote: > On Thu, Feb 20, 2014 at 11:43 PM, Jiang Liu wrote: >> >> >> On 2014/1/3 8:05, Yinghai Lu wrote: >>> iommu irq's irq_desc should be on local node ram. >>> >>> Fix the return value checking problem. >>> create_irq() will return -1 when fail to allocate. >>> create_irq_nr() will return 0 when fail to allocate. >>> here only check !irq, so need to change it to use create_irq_nr instead. >>> >>> -v2: According to Sebastian, add cc to stable. >>> >>> Signed-off-by: Yinghai Lu >>> Cc: Joerg Roedel >>> Cc: Donald Dutile >>> Acked-by: Donald Dutile >>> Cc: Sebastian Andrzej Siewior >>> Cc: sta...@vger.kernel.org >>> --- >>> drivers/iommu/dmar.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c >>> index 8b452c9..f4eaa50 100644 >>> --- a/drivers/iommu/dmar.c >>> +++ b/drivers/iommu/dmar.c >>> @@ -1277,7 +1277,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu) >>> if (iommu->irq) >>> return 0; >>> >>> - irq = create_irq(); >>> + irq = create_irq_nr(0, iommu->node); >> Hi Yinghai, >> How about create_irq_nrq(1, iommu->node) here to clearly state >> that 0 is not a valid irq number for dmar here? > > Should be the same. that 0 or 1 will be from in __create_irqs(). > > And we have > if (from < nr_irqs_gsi) > from = nr_irqs_gsi; > in __create_irqs(). Hi Yinghai, Seems there is no such protection on IA64 side. I feel create_irq_nr() returns 0 for error is a little risky, 0 may be a valid IRQ number on other platforms(no sure about this). Thanks! > > Thanks > > Yinghai > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] regulator: max14577: Fix invalid return value on DT parse success
On Fri, Feb 21, 2014 at 01:12:38PM +0100, Krzysztof Kozlowski wrote: > This fixes bug introduced in 667a6b7a (regulator: max14577: Add missing > of_node_put). The DTS parsing function returned number of matched > regulators as success status which then was compared against 0 in probe. Applied, thanks. signature.asc Description: Digital signature
pull request: bluetooth-next 2014-02-21
Hi John, This is our first pull request for 3.15, the main feature here is the addition of the privacy feature for low energy devices. Other than that we have a bunch of small improvements, fixes, and clean ups all over the tree. Please pull or let me know of any concerns you may have. Thanks. Gustavo --- The following changes since commit e57f1734d87aa0e9a00905ed0f0c62f56227: mwifiex: add key material v2 support (2014-02-12 15:36:26 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 668b7b19820b0801c425d31cc27fd6f499050e5c: Bluetooth: Fix iterating wrong list in hci_remove_irk() (2014-02-21 11:07:46 -0300) Andre Guedes (5): Bluetooth: Save connection interval parameters in hci_conn Bluetooth: Group list_head fields from strcut hci_dev together Bluetooth: Introduce le_conn_failed() helper Bluetooth: Introduce connection parameters list Bluetooth: Use connection parameters if any Andrzej Kaczmarek (1): Bluetooth: Fix channel check when binding RFCOMM sock Andy Shevchenko (2): Bluetooth: sort the list of IDs in the source code Bluetooth: append new supported device to the list [0b05:17d0] Johan Hedberg (53): Bluetooth: Fix outgoing authentication requirement check Bluetooth: Fix mgmt error code for negative PIN response Bluetooth: Reorder L2CAP functions to avoid forward declarations Bluetooth: Queue incoming ACL data until BT_CONNECTED state is reached Bluetooth: Remove useless l2cap_seq_list_remove function Bluetooth: Rename L2CAP_CHAN_CONN_FIX_A2MP to L2CAP_CHAN_FIXED Bluetooth: Switch ATT channels to use L2CAP_CHAN_FIXED Bluetooth: Fix BT_SECURITY socket option for fixed channels (ATT) Bluetooth: Fix CID initialization for fixed channels Bluetooth: Fix respecting le_default_mps value Bluetooth: Fix disconnecting L2CAP channel for credits violation Bluetooth: Fix disconnecting L2CAP when a credits overflow occurs Bluetooth: Free up l2cap_chan->sport when initiating a connection Bluetooth: Refuse peer L2CAP address reading when not connected Bluetooth: Refuse peer RFCOMM address reading when not connected Bluetooth: Always use l2cap_chan->psm for returning PSM to user space 2 Bluetooth: Remove unnecessary check for chan->psm Bluetooth: Enable LTK distribution to slave devices Bluetooth: Remove Simultaneous LE & BR/EDR flags from AD Bluetooth: Fix long_term_keys debugfs output Bluetooth: Make LTK key type check more readable Bluetooth: Remove unnecessary LTK type check from hci_add_ltk Bluetooth: Fix differentiating stored master vs slave LTK types Bluetooth: Enable LE L2CAP CoC support by default Bluetooth: Fix missing PDU length checks for SMP Bluetooth: Fix minor whitespace issues in SMP code Bluetooth: Add smp_irk_matches helper function Bluetooth: Add AES crypto context for each HCI device Bluetooth: Add basic IRK management support Bluetooth: Add hci_bdaddr_is_rpa convenience function Bluetooth: Implement mgmt_load_irks command Bluetooth: Enable support for remote IRK distribution Bluetooth: Fix properly ignoring unexpected SMP PDUs Bluetooth: Fix missing address type check for removing LTKs Bluetooth: Remove return values from functions that don't need them Bluetooth: Fix hci_remove_ltk failure when no match is found Bluetooth: Fix completing SMP as peripheral when no keys are expected Bluetooth: Fix removing any IRKs when unpairing devices Bluetooth: Add convenience function for fetching IRKs Bluetooth: Remove SMP data specific crypto context Bluetooth: Track the LE Identity Address in struct hci_conn Bluetooth: Fix updating Identity Address in L2CAP channels Bluetooth: Wait for SMP key distribution completion when pairing Bluetooth: Don't try to look up private addresses as Identity Address Bluetooth: Look up RPA for connection requests with Identity Address Bluetooth: Use Identity Address in Device Found event Bluetooth: Avoid using GFP_ATOMIC where not necessary Bluetooth: Return added key when adding LTKs and IRKs Bluetooth: Move New LTK store hint evaluation into mgmt_new_ltk Bluetooth: Track SMP keys in the SMP context Bluetooth: Move SMP LTK notification after key distribution Bluetooth: Add support for sending New IRK event Bluetooth: Fix iterating wrong list in hci_remove_irk() Jurgen Kramer (1): Bluetooth: btusb: Add IMC Networks (Broadcom based) Lucas De Marchi (1): Bluetooth: allocate static minor for vhci Marcel Holtmann (48): Bluetooth: Add LMP feature definitions for Secure Connections support
Re: [PATCH 2/2] asoc: soc-core: fix coccinelle warnings
On Fri, Feb 21, 2014 at 04:06:10PM +0800, Nenghua Cao wrote: > --- a/sound/soc/soc-core.c > +++ b/sound/soc/soc-core.c > @@ -2413,7 +2413,7 @@ struct snd_kcontrol *snd_soc_cnew(const struct > snd_kcontrol_new *_template, > struct snd_kcontrol *kcontrol; > char *name = NULL; > > - memcpy(, _template, sizeof(template)); > + memcpy(, _template, sizeof(struct snd_kcontrol_new)); > template.index = 0; > > if (!long_name) This looks like a regression - it's better form to use the object name rather than the type of the object since this prevents errors if the type changes. What coccinelle was suggesting here was to replace with a simple assingment statement rather than change the argument within the memcpy(), I think this stops the warning showing because of that issue since it makes it harder for coccinelle to figure out that this is a memcpy() of the whole object. signature.asc Description: Digital signature
Re: [PATCH 1/2] driver: regmap: fix coccinelle warnings
On Fri, Feb 21, 2014 at 04:05:45PM +0800, Nenghua Cao wrote: > From: Nenghua Cao > >/drivers/base/regmap/regmap.c:717:6-33: WARNING: > Comparison to bool. Applied, thanks. Please use subject lines consistent with the subsystem. signature.asc Description: Digital signature
Re: [PATCH] mfd: wm5102: Remove cache_bypass from manual register patching
On Fri, Feb 21, 2014 at 09:38:55AM +, Charles Keepax wrote: > I guess there are two parts here applying the hardware patch and > the manual application of the register patch. Applying the > hardware patch restores registers once it is finished anyway, and > the actual patch is applied by the write sequencer so will go > straight to the hardware. So that really doesn't need the > cache_bypass. Yeah, it's only the manually applied bit that cares. > > Being able to use the regular patch infrastructure would of course be > > nicer but you're going to need to add a callback to allow you to run the > > hardware patch in that case. > I had considered adding bypassed versions of regmap_write and > read. That way you could ensure that the bypass was only active > whilst the regmap lock was held and avoid the problem that way. > What do you think to that idea? I think that's a reasonable idea, though I see you actually did something slightly different (which is sensible and in fact there already). Thinking about this stuff there's also some ideas I discussed with Dimitris for the DSP memories where if it were possible to mark only a section of the register map as cache only the DSP download could be sped up a little by making the DSP memories cache only during download and then syncing at the end to do the actual writes. That way coefficient writes that change defaults in the firmware would get coalesced and possibly some writes to adjacent blocks could be combined too. Probably not a massive win but it'd be nice. signature.asc Description: Digital signature
Re: [PATCH 1/3] regmap: Check stride of register patch as we register it
On Fri, Feb 21, 2014 at 07:37:10PM +, Charles Keepax wrote: > Currently, we check the registers in the patch are aligned to the > register stride everytime we sync the cache and the first time the patch > is written out is unchecked. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/3] regmap: Add API call apply but not register a patch file
On Fri, Feb 21, 2014 at 07:37:11PM +, Charles Keepax wrote: > This patch provides a new regmap API call that allows a patch to be > applied but not registered with the regmap core. Common code between > this and the existing regmap_register_patch function is factored out to > reduce duplication. This is just regmap_multi_reg_write() I think? That already exists, the theory was that we're going to get an optimised version of that for some hardware which can stream things and cut out some overheads though that doesn't seem to have materialised yet. signature.asc Description: Digital signature
Re: [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver
On 22/02/14 00:48, Mark Rutland wrote: [Adding Tony Prisk to Cc] On Fri, Feb 21, 2014 at 06:31:30AM +, Alistair Popple wrote: Currently the ppc-of driver uses the compatibility string "usb-ehci". This means platforms that use device-tree and implement an EHCI compatible interface have to either use the ppc-of driver or add a compatible line to the ehci-platform driver. It would be more appropriate for the platform driver to be compatible with "usb-ehci" as non-powerpc platforms are also beginning to utilise device-tree. This patch merges the device tree property parsing from ehci-ppc-of into the platform driver and adds a "usb-ehci" compatibility string. The existing ehci-ppc-of driver is removed and the 440EPX specific quirks are added to the ehci-platform driver. Signed-off-by: Alistair Popple --- drivers/usb/host/Kconfig |7 +- drivers/usb/host/ehci-hcd.c |5 - drivers/usb/host/ehci-platform.c | 87 +- drivers/usb/host/ehci-ppc-of.c | 238 -- 4 files changed, 89 insertions(+), 248 deletions(-) delete mode 100644 drivers/usb/host/ehci-ppc-of.c Please use of_property_read_bool for these. This driver already handles "via,vt8500-ehci" and "wm,prizm-ehci" which aren't documented to handle these properties, but now gain support for them. It might be worth unifying the binding documents if there's nothing special about those two host controllers. We seem to have two binding documents for "via,vt8500-ehci", so some cleanup is definitely in order. Tony, you seem to have written both documents judging by 95e9fd10f06c and 8ad551d150e3. Do you have any issue with merging both of these into a common usb-ehci document? .. Cheers, Mark. I'm not sure how we ended up with two bindings for the driver anyway. I think this was an error on my part somewhere. None of the in-tree dts files use "wm,prizm-ehci". I have no issue with merging all the documentation into a single usb-ehci binding. Regards Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: put_page on transparent huge page leaks?
On Fri, Feb 21, 2014 at 11:23:39AM -0600, Jay Cornwall wrote: > Hi, > > I'm tracking a possible memory leak in iommu/amd. The driver uses this logic > to fault a page in response to a PRI from a device: > > npages = get_user_pages(fault->state->task, fault->state->mm, > fault->address, 1, write, 0, , NULL); > > if (npages == 1) > put_page(page); > else > ... > > This works correctly when get_user_pages returns a 4KB page. When > transparent huge pages are enabled any 2MB page returned by this call > appears to leak on process exit. The non-cached memory usage stays elevated > by the set of faulted 2MB pages. This behavior is not observed when the > exception handler demand faults 2MB pages. > > I notice there is a difference in reference count between the 4KB/2MB paths. > > get_user_pages (4KB): page_count()=3, page_mapcount()=1 > put_page (4KB): page_count()=2, page_mapcount()=1 > > get_user_pages (2MB): page_count()=3, page_mapcount()=1 > put_page (2MB): page_count()=3, page_mapcount()=0 > > I'm concerned that the driver appears to be holding a reference count after > put_page(). Am I interpreting this observation correctly? Could you show output of dump_page() on 2M pages for both points? My guess is that your page is PageTail(). Refcounting for tail pages is different: on get_page() we increase *->_mapcount* of tail and increase ->_count of relevant head page. ->_count of tail pages should always be zero, but it's 3 in your case which is odd. BTW, I don't see where you take mmap_sem in drivers/iommu/amd_iommu_v2.c, which is required for gup. Do I miss something? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sisusb: Use static const, fix typo
Reduce text a bit by using static const.
Fix a symmetric typo and neaten a dev_info call
to 80 columns.
$ size drivers/usb/misc/sisusbvga/sisusb.o*
textdata bss dec hex filename
3001648419180 44037ac05 drivers/usb/misc/sisusbvga/sisusb.o.new
3008748419180 44108ac4c drivers/usb/misc/sisusbvga/sisusb.o.old
Signed-off-by: Joe Perches
---
drivers/usb/misc/sisusbvga/sisusb.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/misc/sisusbvga/sisusb.c
b/drivers/usb/misc/sisusbvga/sisusb.c
index de98906..1f89633 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2123,8 +2123,9 @@ sisusb_get_ramconfig(struct sisusb_usb_data *sisusb)
u8 tmp8, tmp82, ramtype;
int bw = 0;
char *ramtypetext1 = NULL;
- const char *ramtypetext2[] = { "SDR SDRAM", "SDR SGRAM",
- "DDR SDRAM", "DDR SGRAM" };
+ static const char *ramtypetext2[] = {
+ "SDR SDRAM", "SDR SGRAM", "DDR SDRAM", "DDR SGRAM"
+ };
static const int busSDR[4] = {64, 64, 128, 128};
static const int busDDR[4] = {32, 32, 64, 64};
static const int busDDRA[4] = {64+32, 64+32 , (64+32)*2, (64+32)*2};
@@ -2146,7 +2147,7 @@ sisusb_get_ramconfig(struct sisusb_usb_data *sisusb)
sisusb->vramsize <<= 1;
bw = busSDR[(tmp8 & 0x03)];
break;
- case 2: ramtypetext1 = "asymmeric";
+ case 2: ramtypetext1 = "asymmetric";
sisusb->vramsize += sisusb->vramsize/2;
bw = busDDRA[(tmp8 & 0x03)];
break;
@@ -2156,8 +2157,9 @@ sisusb_get_ramconfig(struct sisusb_usb_data *sisusb)
break;
}
- dev_info(>sisusb_dev->dev, "%dMB %s %s, bus width %d\n",
(sisusb->vramsize >> 20), ramtypetext1,
- ramtypetext2[ramtype], bw);
+ dev_info(>sisusb_dev->dev, "%dMB %s %s, bus width %d\n",
+sisusb->vramsize >> 20, ramtypetext1, ramtypetext2[ramtype],
+bw);
}
static int
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: msm: switch Kconfig to ARCH_QCOM depends
On Sat, Feb 22, 2014 at 12:33 AM, Kumar Gala wrote: > > On Feb 11, 2014, at 2:22 PM, Kumar Gala wrote: > >> We've split Qualcomm MSM support into legacy and multiplatform. The gpio >> msm-v2 driver is only relevant on the multiplatform supported SoCs so >> switch the Kconfig depends to ARCH_QCOM. >> >> CC: Linus Walleij >> Signed-off-by: Kumar Gala >> --- >> Linus, >> >> If you can ack this I'll send it via linux-qcom/arm-soc tree's >> >> thanks >> >> - k > > ping. Linus is slow to answer for some reason, but I guess that as the co-maintainer my Ack would do for such a simple patch? Acked-by: Alexandre Courbot Linus, please rap on my knuckles if you feel I overstepped. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13 00/99] 3.13.5-stable review
At Thu, 20 Feb 2014 15:51:55 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.13.5 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Feb 22 23:51:00 UTC 2014. > Anything received after that time might be too late. All 3.4.82-rc1, 3.10.32-rc1, 3.12.13-rc1, and 3.13.5-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru Takeuchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: hang in migrate_swap
On 02/22/2014 12:43 AM, Sasha Levin wrote: > On 02/19/2014 11:32 PM, Michael wang wrote: >> On 02/20/2014 02:08 AM, Sasha Levin wrote: >>> >Hi all, >>> > >>> >While fuzzing with trinity inside a KVM tools guest, running latest >>> >-next kernel, I see to hit the following hang quite often. >> Fix for the stuck issue around idle_balance() is now in progress, this >> may caused be the same problem, I suggest we do some retest after these >> patch got merged. > > Could I get a link to the patch please? It's a pain testing other things > with this issue reproducing every time. Please take a try on the latest tip tree, patches has been merged as I saw :) Regards, Michael Wang > > > Thanks, > Sasha > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 2/4] net: enables interface option to skip IP
On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote: > Check this how current Xen scripts does routed networking: > > http://wiki.xen.org/wiki/Xen_Networking#Associating_routes_with_virtual_devices > > Note, there are no bridges involved here! As the above page says, the > backend has to have IP address, maybe it's not true anymore. I'm not too > familiar with this setup too, I've used it only once. Thanks, in such case I do think actually adding a bridge, adding the backend interface to it, and then adding a route to the front end IP would suffice to cover that case, but I'm pretty limited with test devices so would appreciate if someone with a setup like that can test it as an alternative. Please recall that the possible gains here should be pretty significant in terms of simplification. And of course, I still also haven't had time / systems to test the NAT case... 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 v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
On 02/21/2014 12:28 PM, Peter Zijlstra wrote:
On Mon, Feb 17, 2014 at 03:41:24PM -0500, Waiman Long wrote:
+ struct {
+ u8 lock; /* Lock bit */
+ u8 wait; /* Waiting bit */
+ u16 qcode; /* Queue code */
+ };
16 bit code would result in 14 bits for the CPU number, that's only 16k,
I think SGI actually had a machine with that many CPUs in.
If NR_CPUS >= 16k, the 2-task optimized code path will be disabled.
However, with that many CPUs, it is high spinlock contention behavior
that is more important than a bit better performance at low contention
level.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
On Fri, Feb 21, 2014 at 8:01 AM, Luis R. Rodriguez wrote: > On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote: >>> Agreed that's the best strategy and I'll work on sending patches to >>> brctl to enable the root_block preference. This approach however also >> >> I don't think brctl should deal with any Xen specific stuff. I assume there >> is a misunderstanding in this thread: when I (and possibly other Xen folks) >> talk about "userspace" or "toolstack" here, I mean Xen specific tools which >> use e.g. brctl to set up bridges. Not brctl itself. > > I did mean brctl, but as I looked at the code it doesn't used > rtnl_open() and not sure if Stephen would want that. Actually that'd be the incorrect tool to extend, iproute2 would be the new way with: ip link add dev xenbr0 type bridge ip link set dev eth0 master xenbr0 ip link set dev vif1.0 master xenbr0 where root_block would be the new desired argument. This would use the rtnetlink RTM_SETLINK + IFLA_MASTER, which will in turn kick off the bridge ndo_add_slave(). Still though it seems this requires the eth0 device to actually exist and as such from what I can tell we can't set the root_block preference until *after* the addition onto the bridge, which should mean the bridge could still take the vif1.0 MAC address momentarily. This is of course only an issue if the link was up during the additions. This makes me think perhaps nothing is needed then and scripts could just use the: bridge link set dev vif1.0 root_block on I also just noticed that if an entry that was the bridge root port got a root_block toggle we don't kick off the newly blocked port, I just verified this. Note that removing the interface from the bridge does however reset the bridge with a proper new root port: ip link set dev vif1.0 nomaster For old userspace with brctl and no iproute2 we're shit out of luck, this means we can't use root block (xen-netblock was added on v2.6.39). Stephen all this can we add the priv_flags flag to help out as proposed, but I'd make it just toggle the new root_block flag, that'd enable drivers to use this from initialization. Let me know if you have other suggestions or things I may have missed. 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 v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
On 02/21/2014 12:26 PM, Peter Zijlstra wrote: On Fri, Feb 21, 2014 at 12:09:57PM -0500, Waiman Long wrote: On 02/21/2014 12:08 PM, Waiman Long wrote: On 02/21/2014 07:12 AM, Peter Zijlstra wrote: Why is this x86 only code? The code is making use of the fact that byte write is atomic which is true in x86 and probably in a few other architectures. I could pull these codes into the generic qspinlock.c file and set a flag in the asm header file to activate it if it is what you want. -Longman BTW, I also assume that 8-bit and 16-bit cmpxchg() and xchg() are available. Right, screw Alpha :-) Just pull it into the generic code; its far too much code to replicate per arch. OK, I will do that in the next version. -Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Add test for char * arrays that could be static const
static const char* arrays create smaller text as each
function call does not have to populate the array.
Emit a warning when char *arrays aren't static const
and the array is not apparently global by being
declared in the first column.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 646295c..2e6257b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2675,6 +2675,13 @@ sub process {
$herecurr);
}
+# check for non-global char *foo[] = {"bar", ...} declarations.
+ if ($line =~
/^.\s+(?:static\s+|const\s+)?char\s+\*\s*\w+\s*\[\s*\]\s*=\s*\{/) {
+ WARN("STATIC_CONST_CHAR_ARRAY",
+"char * array declaration might be better as
static const\n" .
+ $herecurr);
+ }
+
# check for function declarations without arguments like "int foo()"
if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
if (ERROR("FUNCTION_WITHOUT_ARGS",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm: kernel BUG at mm/huge_memory.c:1371!
On 02/21/2014 06:51 PM, Kirill A. Shutemov wrote: On Fri, Feb 21, 2014 at 05:46:36PM -0500, Sasha Levin wrote: >Hi all, > >While fuzzing with trinity inside a KVM tools guest running latest -next >kernel I've stumbled on the following (now with pretty line numbers!) spew: > >[ 746.125099] kernel BUG at mm/huge_memory.c:1371! It "VM_BUG_ON_PAGE(!PageHead(page), page);", correct? I don't see dump_page() output. Right. However, I'm not seeing the dump_page() output in the log. I see that dump_page() has been modified not long ago, I'm looking into it. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sched/deadline: Prevent rt_time growth to infinity
On 21.02.2014 20:36, Juri Lelli wrote:
> On Fri, 21 Feb 2014 11:37:15 +0100
> Peter Zijlstra wrote:
>
>> On Thu, Feb 20, 2014 at 02:16:00AM +0400, Kirill Tkhai wrote:
>>> Since deadline tasks share rt bandwidth, we must care about
>>> bandwidth timer set. Otherwise rt_time may grow up to infinity
>>> in update_curr_dl(), if there are no other available RT tasks
>>> on top level bandwidth.
>>>
>>> I'm going to decide the problem the way below. Almost untested
>>> because of I skipped almost all of recent patches which haveto be applied
>>> from lkml.
>>>
>>> Please say, if I skipped anything in idea. Maybe better put
>>> start_top_rt_bandwidth() into set_curr_task_dl()?
>>
>> How about we only increment rt_time when there's an RT bandwidth timer
>> active?
>>
>>
>> ---
>> --- a/kernel/sched/rt.c
>> +++ b/kernel/sched/rt.c
>> @@ -568,6 +568,12 @@ static inline struct rt_bandwidth *sched
>>
>> #endif /* CONFIG_RT_GROUP_SCHED */
>>
>> +bool sched_rt_bandwidth_active(struct rt_rq *rt_rq)
>> +{
>> +struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
>> +return hrtimer_active(_b->rt_period_timer);
>> +}
>> +
>> #ifdef CONFIG_SMP
>> /*
>> * We ran out of runtime, see if we can borrow some from our neighbours.
>> --- a/kernel/sched/deadline.c
>> +++ b/kernel/sched/deadline.c
>> @@ -587,6 +587,8 @@ int dl_runtime_exceeded(struct rq *rq, s
>> return 1;
>> }
>>
>> +extern bool sched_rt_bandwidth_active(struct rt_rq *rt_rq);
>> +
>> /*
>> * Update the current task's runtime statistics (provided it is still
>> * a -deadline task and has not been removed from the dl_rq).
>> @@ -650,11 +652,13 @@ static void update_curr_dl(struct rq *rq
>> struct rt_rq *rt_rq = >rt;
>>
>> raw_spin_lock(_rq->rt_runtime_lock);
>> -rt_rq->rt_time += delta_exec;
>> /*
>> * We'll let actual RT tasks worry about the overflow here, we
>> - * have our own CBS to keep us inline -- see above.
>> + * have our own CBS to keep us inline; only account when RT
>> + * bandwidth is relevant.
>> */
>> +if (sched_rt_bandwidth_active(rt_rq))
>> +rt_rq->rt_time += delta_exec;
>> raw_spin_unlock(_rq->rt_runtime_lock);
>> }
>> }
>
> So, I ran some tests with the above and I'd like to share with you what
> I've found. You can find here a trace-cmd trace that should be feeded
> to kernelshark to be able to understand what follows (or feel free to
> reproduce same scenario :)):
> http://retis.sssup.it/~jlelli/traces/trace_rt_time.dat
>
> Here you have a DL task (4/10) and a while(1) RT task, both running
> inside a rt_bw of 0.5. RT tasks is activated 500ms after DL. As I
> filtered in sched_rt_period_timer(), you can search for time instants
> when the rt_bw is replenished. It is evident that the first time after
> rt timer is activated back (search for start_bandwidth_timer), we can
> eat some bw to FAIR tasks (if any). This is due to the fact that we
> reset rt_bw budget at this time, start decrementing rt_time for both DL
> and RT tasks, throttle RT tasks when rt_time > runtime, but, since DL
> tasks acually executes inside their own server, they don't care about
> rt_bw. Good news is that steady state is ok: keeping track of overruns
> we are able to stop eating bw to other guys.
>
> My thougths:
>
> - Peter's patch is an easy fix to Kirill's problem (RT tasks were
>throttled too early);
> - something to add to this solution could be to pre-calculate bw of
>ready DL tasks and subtract it to rt_bw at replenishment time, but
>it sounds quite awkward, pessimistic, and I'm not sure it is gonna
>work;
> - we are stealing bw to best-effort tasks, and just at the beginning
>of the transistion, is it really a problem?
> - I mean, if you want guarantees make your tasks DL! :);
> - in the long run we are gonna have RT tasks scheduled inside CBS
>servers, and all this will be properly fixed up.
>
> Comments?
>
> BTW, rt timer activation/deactivation should probably be fixed for
> !RT_GROUP_SCHED with something like this:
>
> ---
> kernel/sched/rt.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 6161de8..274f992 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -86,12 +86,12 @@ void init_rt_rq(struct rt_rq *rt_rq, struct rq *rq)
> raw_spin_lock_init(_rq->rt_runtime_lock);
> }
>
> -#ifdef CONFIG_RT_GROUP_SCHED
> static void destroy_rt_bandwidth(struct rt_bandwidth *rt_b)
> {
> hrtimer_cancel(_b->rt_period_timer);
> }
>
> +#ifdef CONFIG_RT_GROUP_SCHED
> #define rt_entity_is_task(rt_se) (!(rt_se)->my_q)
>
> static inline struct task_struct *rt_task_of(struct sched_rt_entity *rt_se)
> @@ -1017,8 +1017,12 @@ inc_rt_group(struct sched_rt_entity *rt_se, struct
> rt_rq *rt_rq)
> start_rt_bandwidth(_rt_bandwidth);
[RFC] [PATCH 3/6] media: em28xx-dvb - implement em28xx_ops: suspend/resume hooks
Implement em28xx_ops: suspend/resume hooks. em28xx usb driver will
invoke em28xx_ops: suspend and resume hooks for all its extensions
from its suspend() and resume() interfaces.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-dvb.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a0a669e..736b674 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1492,11 +1492,68 @@ static int em28xx_dvb_fini(struct em28xx *dev)
return 0;
}
+static int em28xx_dvb_suspend(struct em28xx *dev)
+{
+ int ret = 0;
+
+ if (dev->is_audio_only)
+ return 0;
+
+ if (!dev->board.has_dvb)
+ return 0;
+
+ em28xx_info("Suspending DVB extension");
+ if (dev->dvb) {
+ struct em28xx_dvb *dvb = dev->dvb;
+
+ if (dvb->fe[0]) {
+ ret = dvb_frontend_suspend(dvb->fe[0]);
+ em28xx_info("fe0 suspend %d", ret);
+ }
+ if (dvb->fe[1]) {
+ dvb_frontend_suspend(dvb->fe[1]);
+ em28xx_info("fe1 suspend %d", ret);
+ }
+ }
+
+ return 0;
+}
+
+static int em28xx_dvb_resume(struct em28xx *dev)
+{
+ int ret = 0;
+
+ if (dev->is_audio_only)
+ return 0;
+
+ if (!dev->board.has_dvb)
+ return 0;
+
+ em28xx_info("Resuming DVB extension");
+ if (dev->dvb) {
+ struct em28xx_dvb *dvb = dev->dvb;
+
+ if (dvb->fe[0]) {
+ ret = dvb_frontend_resume(dvb->fe[0]);
+ em28xx_info("fe0 resume %d", ret);
+ }
+
+ if (dvb->fe[1]) {
+ ret = dvb_frontend_resume(dvb->fe[1]);
+ em28xx_info("fe1 resume %d", ret);
+ }
+ }
+
+ return 0;
+}
+
static struct em28xx_ops dvb_ops = {
.id = EM28XX_DVB,
.name = "Em28xx dvb Extension",
.init = em28xx_dvb_init,
.fini = em28xx_dvb_fini,
+ .suspend = em28xx_dvb_suspend,
+ .resume = em28xx_dvb_resume,
};
static int __init em28xx_dvb_register(void)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 6/6] media: em28xx - implement em28xx_usb_driver suspend, resume, reset_resume hooks
Implement em28xx_usb_driver suspend, resume, and reset_resume hooks.
These hooks will invoke em28xx core em28xx_suspend_extension() and
em28xx_resume_extension() to suspend and resume registered extensions.
Approach:
Add power management support to em28xx usb driver. This driver works in
conjunction with extensions for each of the functions on the USB device
for video/audio/dvb/remote functionality that is present on media USB
devices it supports. During suspend and resume each of these extensions
will have to do their part in suspending the components they control.
Adding suspend and resume hooks to the existing struct em28xx_ops will
enable the extensions the ability to implement suspend and resume hooks
to be called from em28xx driver. The overall approach is as follows:
-- add suspend and resume hooks to em28xx_ops
-- add suspend and resume routines to em28xx-core to invoke suspend
and resume hooks for all registered extensions.
-- change em28xx dvb, audio, input, and video extensions to implement
em28xx_ops: suspend and resume hooks. These hooks do what is necessary
to suspend and resume the devices they control.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-cards.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 2401240..2e68f51 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3395,10 +3395,36 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
}
}
+static int em28xx_usb_suspend(struct usb_interface *interface,
+ pm_message_t message)
+{
+ struct em28xx *dev;
+
+ dev = usb_get_intfdata(interface);
+ if (!dev)
+ return 0;
+ em28xx_suspend_extension(dev);
+ return 0;
+}
+
+static int em28xx_usb_resume(struct usb_interface *interface)
+{
+ struct em28xx *dev;
+
+ dev = usb_get_intfdata(interface);
+ if (!dev)
+ return 0;
+ em28xx_resume_extension(dev);
+ return 0;
+}
+
static struct usb_driver em28xx_usb_driver = {
.name = "em28xx",
.probe = em28xx_usb_probe,
.disconnect = em28xx_usb_disconnect,
+ .suspend = em28xx_usb_suspend,
+ .resume = em28xx_usb_resume,
+ .reset_resume = em28xx_usb_resume,
.id_table = em28xx_id_table,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 5/6] media: em28xx-video - implement em28xx_ops: suspend/resume hooks
Implement em28xx_ops: suspend/resume hooks. em28xx usb driver will
invoke em28xx_ops: suspend and resume hooks for all its extensions
from its suspend() and resume() interfaces.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-video.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index c3c9289..1df6750 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1933,6 +1933,32 @@ static int em28xx_v4l2_fini(struct em28xx *dev)
return 0;
}
+static int em28xx_v4l2_suspend(struct em28xx *dev)
+{
+ if (dev->is_audio_only)
+ return 0;
+
+ if (!dev->has_video)
+ return 0;
+
+ em28xx_info("Suspending video extension");
+ em28xx_stop_urbs(dev);
+ return 0;
+}
+
+static int em28xx_v4l2_resume(struct em28xx *dev)
+{
+ if (dev->is_audio_only)
+ return 0;
+
+ if (!dev->has_video)
+ return 0;
+
+ em28xx_info("Resuming video extension");
+ /* what do we do here */
+ return 0;
+}
+
/*
* em28xx_v4l2_close()
* stops streaming and deallocates all resources allocated by the v4l2
@@ -2504,6 +2530,8 @@ static struct em28xx_ops v4l2_ops = {
.name = "Em28xx v4l2 Extension",
.init = em28xx_v4l2_init,
.fini = em28xx_v4l2_fini,
+ .suspend = em28xx_v4l2_suspend,
+ .resume = em28xx_v4l2_resume,
};
static int __init em28xx_video_register(void)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 2/6] media: em28xx-audio - implement em28xx_ops: suspend/resume hooks
Implement em28xx_ops: suspend/resume hooks. em28xx usb driver will
invoke em28xx_ops: suspend and resume hooks for all its extensions
from its suspend() and resume() interfaces.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-audio.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 05e9bd1..a4d159d 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -989,11 +989,41 @@ static int em28xx_audio_fini(struct em28xx *dev)
return 0;
}
+static int em28xx_audio_suspend(struct em28xx *dev)
+{
+ if (dev == NULL)
+ return 0;
+
+ if (!dev->has_alsa_audio)
+ return 0;
+
+ em28xx_info("Suspending audio extension");
+ em28xx_deinit_isoc_audio(dev);
+ atomic_set(>stream_started, 0);
+ return 0;
+}
+
+static int em28xx_audio_resume(struct em28xx *dev)
+{
+ if (dev == NULL)
+ return 0;
+
+ if (!dev->has_alsa_audio)
+ return 0;
+
+ em28xx_info("Resuming audio extension");
+ /* Nothing to do other than schedule_work() ?? */
+ schedule_work(>wq_trigger);
+ return 0;
+}
+
static struct em28xx_ops audio_ops = {
.id = EM28XX_AUDIO,
.name = "Em28xx Audio Extension",
.init = em28xx_audio_init,
.fini = em28xx_audio_fini,
+ .suspend = em28xx_audio_suspend,
+ .resume = em28xx_audio_resume,
};
static int __init em28xx_alsa_register(void)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 4/6] media: em28xx-input - implement em28xx_ops: suspend/resume hooks
Implement em28xx_ops: suspend/resume hooks. em28xx usb driver will
invoke em28xx_ops: suspend and resume hooks for all its extensions
from its suspend() and resume() interfaces.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-input.c | 35 +
1 file changed, 35 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 18f65d8..1227309 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -827,11 +827,46 @@ static int em28xx_ir_fini(struct em28xx *dev)
return 0;
}
+static int em28xx_ir_suspend(struct em28xx *dev)
+{
+ struct em28xx_IR *ir = dev->ir;
+
+ if (dev->is_audio_only)
+ return 0;
+
+ em28xx_info("Suspending input extension");
+ cancel_delayed_work_sync(>work);
+ cancel_delayed_work_sync(>buttons_query_work);
+ /* is canceling delayed work sufficient or does the rc event
+ kthread needs stopping? kthread is stopped in
+ ir_raw_event_unregister() */
+ return 0;
+}
+
+static int em28xx_ir_resume(struct em28xx *dev)
+{
+ struct em28xx_IR *ir = dev->ir;
+
+ if (dev->is_audio_only)
+ return 0;
+
+ em28xx_info("Resuming input extension");
+ /* if suspend calls ir_raw_event_unregister(), the should call
+ ir_raw_event_register() */
+ schedule_delayed_work_sync(>work);
+ if (dev->num_button_polling_addresses)
+ schedule_delayed_work(>buttons_query_work,
+ msecs_to_jiffies(dev->button_polling_interval));
+ return 0;
+}
+
static struct em28xx_ops rc_ops = {
.id = EM28XX_RC,
.name = "Em28xx Input Extension",
.init = em28xx_ir_init,
.fini = em28xx_ir_fini,
+ .suspend = em28xx_ir_suspend,
+ .resume = em28xx_ir_resume,
};
static int __init em28xx_rc_register(void)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 1/6] media: em28xx - add suspend/resume to em28xx_ops
em28xx usb driver will have to suspend and resume its extensions. Adding
suspend and resume to em28xx_ops gives extensions the ability to install
suspend and resume that can be invoked from em28xx_usb driver suspend()
and resume() interfaces.
Approach:
Add power management support to em28xx usb driver. This driver works in
conjunction with extensions for each of the functions on the USB device
for video/audio/dvb/remote functionality that is present on media USB
devices it supports. During suspend and resume each of these extensions
will have to do their part in suspending the components they control.
Adding suspend and resume hooks to the existing struct em28xx_ops will
enable the extensions the ability to implement suspend and resume hooks
to be called from em28xx driver. The overall approach is as follows:
-- add suspend and resume hooks to em28xx_ops
-- add suspend and resume routines to em28xx-core to invoke suspend
and resume hooks for all registered extensions.
-- change em28xx dvb, audio, input, and video extensions to implement
em28xx_ops: suspend and resume hooks. These hooks do what is necessary
to suspend and resume the devices they control.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-core.c | 28
drivers/media/usb/em28xx/em28xx.h | 4
2 files changed, 32 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index 898fb9b..6de41c6 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -1106,3 +1106,31 @@ void em28xx_close_extension(struct em28xx *dev)
list_del(>devlist);
mutex_unlock(_devlist_mutex);
}
+
+int em28xx_suspend_extension(struct em28xx *dev)
+{
+ const struct em28xx_ops *ops = NULL;
+
+ em28xx_info("Suspending extensions");
+ mutex_lock(_devlist_mutex);
+ list_for_each_entry(ops, _extension_devlist, next) {
+ if (ops->suspend)
+ ops->suspend(dev);
+ }
+ mutex_unlock(_devlist_mutex);
+ return 0;
+}
+
+int em28xx_resume_extension(struct em28xx *dev)
+{
+ const struct em28xx_ops *ops = NULL;
+
+ em28xx_info("Resuming extensions");
+ mutex_lock(_devlist_mutex);
+ list_for_each_entry(ops, _extension_devlist, next) {
+ if (ops->resume)
+ ops->resume(dev);
+ }
+ mutex_unlock(_devlist_mutex);
+ return 0;
+}
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 32d8a4b..9b02f15 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -713,6 +713,8 @@ struct em28xx_ops {
int id;
int (*init)(struct em28xx *);
int (*fini)(struct em28xx *);
+ int (*suspend)(struct em28xx *);
+ int (*resume)(struct em28xx *);
};
/* Provided by em28xx-i2c.c */
@@ -758,6 +760,8 @@ int em28xx_register_extension(struct em28xx_ops *dev);
void em28xx_unregister_extension(struct em28xx_ops *dev);
void em28xx_init_extension(struct em28xx *dev);
void em28xx_close_extension(struct em28xx *dev);
+int em28xx_suspend_extension(struct em28xx *dev);
+int em28xx_resume_extension(struct em28xx *dev);
/* Provided by em28xx-cards.c */
extern struct em28xx_board em28xx_boards[];
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH 0/6] media: em28xx - power management support em28xx
Add power management support to em28xx usb driver. This driver works in conjunction with extensions for each of the functions on the USB device for video/audio/dvb/remote functionality that is present on media USB devices it supports. During suspend and resume each of these extensions will have to do their part in suspending the components they control. Adding suspend and resume hooks to the existing struct em28xx_ops will enable the extensions the ability to implement suspend and resume hooks to be called from em28xx driver. The overall approach is as follows: -- add suspend and resume hooks to em28xx_ops -- add suspend and resume routines to em28xx-core to invoke suspend and resume hooks for all registered extensions. -- change em28xx dvb, audio, input, and video extensions to implement em28xx_ops: suspend and resume hooks. These hooks do what is necessary to suspend and resume the devices they control. Shuah Khan (6): media: em28xx - add suspend/resume to em28xx_ops media: em28xx-audio - implement em28xx_ops: suspend/resume hooks media: em28xx-dvb - implement em28xx_ops: suspend/resume hooks media: em28xx-input - implement em28xx_ops: suspend/resume hooks media: em28xx-video - implement em28xx_ops: suspend/resume hooks media: em28xx - implement em28xx_usb_driver suspend, resume, reset_resume hooks drivers/media/usb/em28xx/em28xx-audio.c | 30 + drivers/media/usb/em28xx/em28xx-cards.c | 26 +++ drivers/media/usb/em28xx/em28xx-core.c | 28 drivers/media/usb/em28xx/em28xx-dvb.c | 57 + drivers/media/usb/em28xx/em28xx-input.c | 35 drivers/media/usb/em28xx/em28xx-video.c | 28 drivers/media/usb/em28xx/em28xx.h | 4 +++ 7 files changed, 208 insertions(+) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 28/35] qlcnic: Use pci_enable_msix_range() instead of pci_enable_msix()
On Sat, 2014-02-22 at 00:44 +, Ben Hutchings wrote:
> On Tue, 2014-02-18 at 11:11 +0100, Alexander Gordeev wrote:
> > As result of deprecation of MSI-X/MSI enablement functions
> > pci_enable_msix() and pci_enable_msi_block() all drivers
> > using these two interfaces need to be updated to use the
> > new pci_enable_msi_range() and pci_enable_msix_range()
> > interfaces.
[...]
> > --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> > +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> > @@ -701,13 +701,17 @@ enable_msix:
> > for (vector = 0; vector < num_msix; vector++)
> > adapter->msix_entries[vector].entry = vector;
> >
> > - err = pci_enable_msix(pdev, adapter->msix_entries, num_msix);
> > - if (err == 0) {
> > + err = pci_enable_msix_range(pdev,
> > + adapter->msix_entries, 1, num_msix);
> > +
> > + if (err == num_msix) {
> > adapter->flags |= QLCNIC_MSIX_ENABLED;
> > adapter->ahw->num_msix = num_msix;
> > dev_info(>dev, "using msi-x interrupts\n");
> > return 0;
> > } else if (err > 0) {
> > + pci_disable_msix(pdev);
> > +
> > dev_info(>dev,
> > "Unable to allocate %d MSI-X vectors,
> > Available vectors %d\n",
> > num_msix, err);
>
> Well this log message is nonsense - we have no idea how many vectors are
> available any more.
>
> You should remove this and the retry loop that is no longer needed.
Sorry, I'm confused and this does work. But I wonder whether it is
really an improvement over using the old API.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Re: linux-next: manual merge of the arm-soc tree with the arm-perf tree
On Fri, Feb 21, 2014 at 3:09 AM, Will Deacon wrote:
> On Fri, Feb 21, 2014 at 01:02:47AM +, Olof Johansson wrote:
>> On Thu, Feb 20, 2014 at 4:58 PM, Stephen Rothwell
>> wrote:
>> > Today's linux-next merge of the arm-soc tree got a conflict in
>> > arch/arm/boot/dts/qcom-msm8960-cdp.dts between commit a1d711938959 ("ARM:
>> > dts: msm: Add krait-pmu to platforms with Krait CPUs") from the arm-perf
>> > tree and commit cc60a1a4d47a ("ARM: dts: msm: split out msm8660 and
>> > msm8960 soc into dts include") from the arm-soc tree.
>> >
>> > I fixed it up (probably not the best way ... see below) and can carry the
>> > fix as necessary (no action is required).
>>
>> Will, I think we'll be better off taking dts changes through arm-soc,
>> unless there's a good reason to take them through other trees (such as
>> the perf tree in this case). Is there, or should we move them over?
>
> Sure, I can drop that from my tree (it came as part of the series adding
> Krait PMU support).
>
> I've included the original patch below so you can put it into arm-soc.
Thanks, I've applied it now (with the fixups to move to the dtsi).
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 28/35] qlcnic: Use pci_enable_msix_range() instead of pci_enable_msix()
On Tue, 2014-02-18 at 11:11 +0100, Alexander Gordeev wrote:
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Signed-off-by: Alexander Gordeev
> Cc: Himanshu Madhani
> Cc: Rajesh Borundia
> Cc: Shahed Shaikh
> Cc: linux-dri...@qlogic.com
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> index 0c077cf..e07fd94 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> @@ -701,13 +701,17 @@ enable_msix:
> for (vector = 0; vector < num_msix; vector++)
> adapter->msix_entries[vector].entry = vector;
>
> - err = pci_enable_msix(pdev, adapter->msix_entries, num_msix);
> - if (err == 0) {
> + err = pci_enable_msix_range(pdev,
> + adapter->msix_entries, 1, num_msix);
> +
> + if (err == num_msix) {
> adapter->flags |= QLCNIC_MSIX_ENABLED;
> adapter->ahw->num_msix = num_msix;
> dev_info(>dev, "using msi-x interrupts\n");
> return 0;
> } else if (err > 0) {
> + pci_disable_msix(pdev);
> +
> dev_info(>dev,
>"Unable to allocate %d MSI-X vectors,
> Available vectors %d\n",
>num_msix, err);
Well this log message is nonsense - we have no idea how many vectors are
available any more.
You should remove this and the retry loop that is no longer needed.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH net-next 01/35] bnx2: Use pci_enable_msix_range() instead of pci_enable_msix()
On Tue, 2014-02-18 at 11:07 +0100, Alexander Gordeev wrote:
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Signed-off-by: Alexander Gordeev
> Cc: Michael Chan
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
> drivers/net/ethernet/broadcom/bnx2.c | 15 ---
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c
> b/drivers/net/ethernet/broadcom/bnx2.c
> index cda25ac..ca6b362 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -6206,7 +6206,7 @@ bnx2_free_irq(struct bnx2 *bp)
> static void
> bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
> {
> - int i, total_vecs, rc;
> + int i, total_vecs;
> struct msix_entry msix_ent[BNX2_MAX_MSIX_VEC];
> struct net_device *dev = bp->dev;
> const int len = sizeof(bp->irq_tbl[0].name);
> @@ -6229,16 +6229,9 @@ bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
> #ifdef BCM_CNIC
> total_vecs++;
> #endif
> - rc = -ENOSPC;
> - while (total_vecs >= BNX2_MIN_MSIX_VEC) {
> - rc = pci_enable_msix(bp->pdev, msix_ent, total_vecs);
> - if (rc <= 0)
> - break;
> - if (rc > 0)
> - total_vecs = rc;
> - }
> -
> - if (rc != 0)
> + total_vecs = pci_enable_msix_range(bp->pdev, msix_ent,
> +BNX2_MIN_MSIX_VEC, total_vecs);
> + if (total_vecs < 0)
> return;
This would be better without the assignment to total_vecs.
Ben.
> msix_vecs = total_vecs;
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
[PATCH] powerpc: warn users of smt-snooze-delay that the API isn't there anymore
/sys/devices/system/cpu/cpu*/smt-snooze-delay was converted into a NOP
in commit 3fa8cad82b94d0bed002571bd246f2299ffc876b, and now does
nothing. Add a pr_warn() to convince any users that they should stop
using it.
The commit message from the removing commit notes that this
functionality should move into the cpuidle driver, essentially by
adjusting target_residency to the specified value. At the moment,
target_residency is not exposed by cpuidle's sysfs, so there isn't a
drop in replacement for this.
Signed-off-by: Cody P Schafer
---
arch/powerpc/kernel/sysfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 97e1dc9..84097b4 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -50,6 +50,9 @@ static ssize_t store_smt_snooze_delay(struct device *dev,
if (ret != 1)
return -EINVAL;
+ pr_warn_ratelimited("%s (%d):
/sys/devices/system/cpu/cpu%d/smt-snooze-delay is deprecated and is a NOP\n",
+ current->comm, task_pid_nr(current), cpu->dev.id);
+
per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
return count;
}
@@ -60,6 +63,9 @@ static ssize_t show_smt_snooze_delay(struct device *dev,
{
struct cpu *cpu = container_of(dev, struct cpu, dev);
+ pr_warn_ratelimited("%s (%d):
/sys/devices/system/cpu/cpu%d/smt-snooze-delay is deprecated and is a NOP\n",
+ current->comm, task_pid_nr(current), cpu->dev.id);
+
return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm v3 2/7] memcg, slab: cleanup memcg cache creation
On Thu, 20 Feb 2014 11:22:04 +0400 Vladimir Davydov
wrote:
> This patch cleanups the memcg cache creation path as follows:
> - Move memcg cache name creation to a separate function to be called
>from kmem_cache_create_memcg(). This allows us to get rid of the
>mutex protecting the temporary buffer used for the name formatting,
>because the whole cache creation path is protected by the slab_mutex.
> - Get rid of memcg_create_kmem_cache(). This function serves as a proxy
>to kmem_cache_create_memcg(). After separating the cache name
>creation path, it would be reduced to a function call, so let's
>inline it.
This patch makes a huge mess when it hits linux-next's e61734c5
("cgroup: remove cgroup->name"). In the vicinity of
memcg_create_kmem_cache(). That isn't the first mess e61734c5 made :(
I think I got it all fixed up - please check the end result in
http://ozlabs.org/~akpm/stuff/.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Update 2x][PATCH 6/9] ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devices
From: Rafael J. Wysocki
Modify the SATA subsystem to add hotplug contexts to ACPI companions
of SATA devices and ports instead of registering special ACPI dock
operations using register_hotplug_dock_device().
That change will allow the entire code handling those special ACPI
dock operations to be dropped in the next commit.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
Acked-by: Tejun Heo
---
The previous version caused modular builds of libata-acpi.c to fail because
of the ACPI hotplug context locking wrappers that aren't exported to modules.
I (hopefully) fixed that by introducing a wrapper around acpi_set_hp_context()
that does the locking and is exported.
I retained the Reviewed-by and ACK above, because the change was only cosmetic,
so please let me know if that's not appropriate.
Rafael
---
drivers/acpi/scan.c | 11 +++
drivers/ata/libata-acpi.c | 72 --
include/acpi/acpi_bus.h |5 +++
3 files changed, 61 insertions(+), 27 deletions(-)
Index: linux-pm/drivers/ata/libata-acpi.c
===
--- linux-pm.orig/drivers/ata/libata-acpi.c
+++ linux-pm/drivers/ata/libata-acpi.c
@@ -38,6 +38,16 @@ static void ata_acpi_clear_gtf(struct at
dev->gtf_cache = NULL;
}
+struct ata_acpi_hotplug_context {
+ struct acpi_hotplug_context hp;
+ union {
+ struct ata_port *ap;
+ struct ata_device *dev;
+ } data;
+};
+
+#define ata_hotplug_data(context) (container_of((context), struct
ata_acpi_hotplug_context, hp)->data)
+
/**
* ata_dev_acpi_handle - provide the acpi_handle for an ata_device
* @dev: the acpi_handle returned will correspond to this device
@@ -121,18 +131,17 @@ static void ata_acpi_handle_hotplug(stru
ata_port_wait_eh(ap);
}
-static void ata_acpi_dev_notify_dock(acpi_handle handle, u32 event, void *data)
+static int ata_acpi_dev_notify_dock(struct acpi_device *adev, u32 event)
{
- struct ata_device *dev = data;
-
+ struct ata_device *dev = ata_hotplug_data(adev->hp).dev;
ata_acpi_handle_hotplug(dev->link->ap, dev, event);
+ return 0;
}
-static void ata_acpi_ap_notify_dock(acpi_handle handle, u32 event, void *data)
+static int ata_acpi_ap_notify_dock(struct acpi_device *adev, u32 event)
{
- struct ata_port *ap = data;
-
- ata_acpi_handle_hotplug(ap, NULL, event);
+ ata_acpi_handle_hotplug(ata_hotplug_data(adev->hp).ap, NULL, event);
+ return 0;
}
static void ata_acpi_uevent(struct ata_port *ap, struct ata_device *dev,
@@ -154,31 +163,23 @@ static void ata_acpi_uevent(struct ata_p
}
}
-static void ata_acpi_ap_uevent(acpi_handle handle, u32 event, void *data)
+static void ata_acpi_ap_uevent(struct acpi_device *adev, u32 event)
{
- ata_acpi_uevent(data, NULL, event);
+ ata_acpi_uevent(ata_hotplug_data(adev->hp).ap, NULL, event);
}
-static void ata_acpi_dev_uevent(acpi_handle handle, u32 event, void *data)
+static void ata_acpi_dev_uevent(struct acpi_device *adev, u32 event)
{
- struct ata_device *dev = data;
+ struct ata_device *dev = ata_hotplug_data(adev->hp).dev;
ata_acpi_uevent(dev->link->ap, dev, event);
}
-static const struct acpi_dock_ops ata_acpi_dev_dock_ops = {
- .handler = ata_acpi_dev_notify_dock,
- .uevent = ata_acpi_dev_uevent,
-};
-
-static const struct acpi_dock_ops ata_acpi_ap_dock_ops = {
- .handler = ata_acpi_ap_notify_dock,
- .uevent = ata_acpi_ap_uevent,
-};
-
/* bind acpi handle to pata port */
void ata_acpi_bind_port(struct ata_port *ap)
{
struct acpi_device *host_companion = ACPI_COMPANION(ap->host->dev);
+ struct acpi_device *adev;
+ struct ata_acpi_hotplug_context *context;
if (libata_noacpi || ap->flags & ATA_FLAG_ACPI_SATA || !host_companion)
return;
@@ -188,9 +189,17 @@ void ata_acpi_bind_port(struct ata_port
if (ata_acpi_gtm(ap, >__acpi_init_gtm) == 0)
ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
- /* we might be on a docking station */
- register_hotplug_dock_device(ACPI_HANDLE(>tdev),
-_acpi_ap_dock_ops, ap, NULL, NULL);
+ adev = ACPI_COMPANION(>tdev);
+ if (!adev || adev->hp)
+ return;
+
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (!context)
+ return;
+
+ context->data.ap = ap;
+ acpi_initialize_hp_context(adev, >hp, ata_acpi_ap_notify_dock,
+ ata_acpi_ap_uevent);
}
void ata_acpi_bind_dev(struct ata_device *dev)
@@ -198,7 +207,8 @@ void ata_acpi_bind_dev(struct ata_device
struct ata_port *ap = dev->link->ap;
struct acpi_device *port_companion = ACPI_COMPANION(>tdev);
struct acpi_device *host_companion = ACPI_COMPANION(ap->host->dev);
- struct acpi_device *parent;
+
Re: [PATCH] mm: exclude memory less nodes from zone_reclaim
On 21.02.2014 [14:07:35 -0800], Andrew Morton wrote:
> On Thu, 20 Feb 2014 10:51:44 +0100 Michal Hocko wrote:
>
> > We had a report about strange OOM killer strikes on a PPC machine
> > although there was a lot of swap free and a tons of anonymous memory
> > which could be swapped out. In the end it turned out that the OOM was
> > a side effect of zone reclaim which wasn't doesn't unmap and swapp out
> > and so the system was pushed to the OOM. Although this sounds like a bug
> > somewhere in the kswapd vs. zone reclaim vs. direct reclaim interaction
> > numactl on the said hardware suggests that the zone reclaim should
> > have been set in the first place:
> > node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> > node 0 size: 0 MB
> > node 0 free: 0 MB
> > node 2 cpus:
> > node 2 size: 7168 MB
> > node 2 free: 6019 MB
> > node distances:
> > node 0 2
> > 0: 10 40
> > 2: 40 10
> >
> > So all the CPUs are associated with Node0 which doesn't have any memory
> > while Node2 contains all the available memory. Node distances cause an
> > automatic zone_reclaim_mode enabling.
> >
> > Zone reclaim is intended to keep the allocations local but this doesn't
> > make any sense on the memory less nodes. So let's exclude such nodes
> > for init_zone_allows_reclaim which evaluates zone reclaim behavior and
> > suitable reclaim_nodes.
> >
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1855,7 +1855,7 @@ static void __paginginit init_zone_allows_reclaim(int
> > nid)
> > {
> > int i;
> >
> > - for_each_online_node(i)
> > + for_each_node_state(i, N_MEMORY)
> > if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> > node_set(i, NODE_DATA(nid)->reclaim_nodes);
> > else
> > @@ -4901,7 +4901,8 @@ void __paginginit free_area_init_node(int nid,
> > unsigned long *zones_size,
> >
> > pgdat->node_id = nid;
> > pgdat->node_start_pfn = node_start_pfn;
> > - init_zone_allows_reclaim(nid);
> > + if (node_state(nid, N_MEMORY))
> > + init_zone_allows_reclaim(nid);
> > #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> > get_pfn_range_for_nid(nid, _pfn, _pfn);
> > #endif
>
> What happens if someone later hot-adds some memory to that node?
This probably isn't a very good answer, but I think the question of how
to support a node that starts off memoryless and then gets memory
hot-added later is still open. But this at least gets us further and
would be needed anyways, I think.
I'm going to try and look at the hot-add component after we get this
base stuff in, if that's ok, but it's definitely on my todo list.
Thanks,
Nish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
perf_fuzzer: WARNING arch/x86/kernel/cpu/perf_event.c:1158 x86_pmu_stop
I got this while perf_fuzzing, same core2 machine, this
is 3.14-rc3 *with* Peter's patch to fix the other WARNING applied.
I can try to isolate a test case, though not until after the weekend.
Vince
if (__test_and_clear_bit(hwc->idx, cpuc->active_mask)) {
x86_pmu.disable(event);
cpuc->events[hwc->idx] = NULL;
===>WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
hwc->state |= PERF_HES_STOPPED;
}
[13044.385262] [ cut here ]
[13044.388007] WARNING: CPU: 1 PID: 6274 at
arch/x86/kernel/cpu/perf_event.c:1158 x86_pmu_stop+0x71/0xa6()
[13044.388007] Modules linked in: cpufreq_userspace cpufreq_stats
cpufreq_powersave cpufreq_conservative f71882fg mcs7830 usbnet wmi ohci_pci
acpi_cpufreq video evdev pcspkr psmouse processor coretemp thermal_sys
serio_raw button ohci_hcd i2c_nforce2 ehci_pci ehci_hcd sg sd_mod usbcore
usb_common
[13044.388007] CPU: 1 PID: 6274 Comm: perf_fuzzer Not tainted 3.14.0-rc3+ #18
[13044.388007] Hardware name: AOpen DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012,
BIOS 080015 10/19/2012
[13044.388007] 0486 88011fc83ca8 81530d11
0486
[13044.388007] 88011fc83ce8 8103fce4
810691ac
[13044.388007] 81012ce3 8800cae0e800 0004
88011fc8b940
[13044.388007] Call Trace:
[13044.388007][] dump_stack+0x49/0x60
[13044.388007] [] warn_slowpath_common+0x81/0x9b
[13044.388007] [] ? default_wake_function+0x12/0x14
[13044.388007] [] ? x86_pmu_stop+0x71/0xa6
[13044.388007] [] warn_slowpath_null+0x1a/0x1c
[13044.388007] [] x86_pmu_stop+0x71/0xa6
[13044.388007] [] x86_pmu_del+0x41/0xd2
[13044.388007] [] event_sched_out+0x92/0x121
[13044.388007] [] group_sched_in+0xf7/0x147
[13044.388007] [] ctx_sched_in+0x15e/0x185
[13044.388007] [] perf_event_sched_in+0x69/0x71
[13044.388007] [] perf_cpu_hrtimer_handler+0x13a/0x1b0
[13044.388007] [] __run_hrtimer+0xba/0x145
[13044.388007] [] ? __perf_install_in_context+0xf0/0xf0
[13044.388007] [] hrtimer_interrupt+0xd5/0x1c3
[13044.388007] [] local_apic_timer_interrupt+0x58/0x5d
[13044.388007] [] smp_trace_apic_timer_interrupt+0x53/0x91
[13044.388007] [] trace_apic_timer_interrupt+0x6a/0x70
[13044.388007][] ? system_call_fastpath+0x1a/0x1f
[13044.388007] ---[ end trace 8007361335c0fe73 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] hugetlb: add hugepages_node= command-line option
On Mon, 17 Feb 2014 21:47:36 -0800 Davidlohr Bueso wrote: > > How is that difficult? hugepages= is the "noun", hugepagesz= is the > > "adjective". hugepages=100 hugepagesz=1G hugepages=4 makes perfect sense > > to me, and I actually don't allocate hugepages on the command line, nor > > have I looked at Documentation/kernel-parameters.txt to check if I'm > > constructing it correctly. It just makes sense and once you learn it it's > > just natural. > > This can get annoying _really_ fast for larger systems. Yes, I do prefer the syntax Luiz is proposing. But I think it would be better if it made hugepages= and hugepagesz= obsolete, so we can emit a printk if people use those, telling them to migrate because the old options are going away. Something like hugepages_node=1:4:1G and hugepages_node=:16:1G ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm: kernel BUG at mm/huge_memory.c:1371!
On Fri, Feb 21, 2014 at 05:46:36PM -0500, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next > kernel I've stumbled on the following (now with pretty line numbers!) spew: > > [ 746.125099] kernel BUG at mm/huge_memory.c:1371! It "VM_BUG_ON_PAGE(!PageHead(page), page);", correct? I don't see dump_page() output. > [ 746.125775] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 746.126774] Dumping ftrace buffer: > [ 746.127484](ftrace buffer empty) > [ 746.127781] Modules linked in: > [ 746.128358] CPU: 2 PID: 19816 Comm: trinity-c127 Tainted: GW > 3.14.0-rc3-next-20140221-sasha-8-g0e660cf-dirty #114 > [ 746.130196] task: 8803a7cc3000 ti: 8803a7f1c000 task.ti: > 8803a7f1c000 > [ 746.130317] RIP: 0010:[] [] > zap_huge_pmd+0x17a/0x200 > [ 746.130317] RSP: 0018:8803a7f1dca8 EFLAGS: 00010246 > [ 746.130317] RAX: 8801ab4ac000 RBX: 8803a7f1ddd8 RCX: > 002e > [ 746.130317] RDX: RSI: 8803a7cc3d00 RDI: > 0172c000 > [ 746.130317] RBP: 8803a7f1dce8 R08: R09: > > [ 746.130317] R10: 0001 R11: 0001 R12: > ea0006a8fa00 > [ 746.130317] R13: ea0005cb R14: 7f784f80 R15: > 7f785750bfff > [ 746.130317] FS: 7f785afbc700() GS:8801abc0() > knlGS: > [ 746.130317] CS: 0010 DS: ES: CR0: 8005003b > [ 746.130317] CR2: 0010 CR3: 0003a9739000 CR4: > 06e0 > [ 746.130317] DR0: 00693000 DR1: DR2: > > [ 746.130317] DR3: DR6: 0ff0 DR7: > 0600 > [ 746.130317] Stack: > [ 746.130317] 04de 8803a9777390 8803a7f1dce8 > 8803a2afd3e0 > [ 746.130317] 7f784f80 7f785750c000 8803a7f1ddd8 > 7f785750bfff > [ 746.130317] 8803a7f1dd78 81285536 001d8500 > 7f784fa0 > [ 746.130317] Call Trace: > [ 746.130317] [] > unmap_page_range+0x2c6/0x410 > [ 746.130317] [] unmap_single_vma+0xf1/0x110 > [ 746.130317] [] zap_page_range+0x121/0x170 > [ 746.130317] [] madvise_vma+0x180/0x1c0 > [ 746.130317] [] SyS_madvise+0x17e/0x250 > [ 746.130317] [] tracesys+0xdd/0xe2 > [ 746.152464] Code: 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 81 80 60 03 > 00 00 00 fe ff ff 49 8b 45 00 f6 c4 40 75 18 31 f6 4c 89 ef e8 26 29 f9 ff > <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 ff 48 > [ 746.152464] RIP [] zap_huge_pmd+0x17a/0x200 > [ 746.152464] RSP > > > Thanks, > Sasha > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched/deadline: Prevent rt_time growth to infinity
21.02.2014, 20:52, "Juri Lelli" :
> On Fri, 21 Feb 2014 17:36:41 +0100
> Juri Lelli wrote:
>
>> Â On Fri, 21 Feb 2014 11:37:15 +0100
>> Â Peter Zijlstra wrote:
>>> Â On Thu, Feb 20, 2014 at 02:16:00AM +0400, Kirill Tkhai wrote:
 Since deadline tasks share rt bandwidth, we must care about
 bandwidth timer set. Otherwise rt_time may grow up to infinity
 in update_curr_dl(), if there are no other available RT tasks
 on top level bandwidth.
 I'm going to decide the problem the way below. Almost untested
 because of I skipped almost all of recent patches which haveto be applied
from lkml.
 Please say, if I skipped anything in idea. Maybe better put
 start_top_rt_bandwidth() into set_curr_task_dl()?
>>> Â How about we only increment rt_time when there's an RT bandwidth timer
>>> Â active?
>>>
>>> Â ---
>>> Â --- a/kernel/sched/rt.c
>>> Â +++ b/kernel/sched/rt.c
>>> Â @@ -568,6 +568,12 @@ static inline struct rt_bandwidth *sched
>>>
>>> Â Â #endif /* CONFIG_RT_GROUP_SCHED */
>>>
>>> Â +bool sched_rt_bandwidth_active(struct rt_rq *rt_rq)
>>> Â +{
>>> Â + struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
>>> Â + return hrtimer_active(_b->rt_period_timer);
>>> Â +}
>>> Â +
>>> Â Â #ifdef CONFIG_SMP
>>> Â Â /*
>>> Â Â Â * We ran out of runtime, see if we can borrow some from our neighbours.
>>> Â --- a/kernel/sched/deadline.c
>>> Â +++ b/kernel/sched/deadline.c
>>> Â @@ -587,6 +587,8 @@ int dl_runtime_exceeded(struct rq *rq, s
>>> Â Â return 1;
>>> Â Â }
>>>
>>> Â +extern bool sched_rt_bandwidth_active(struct rt_rq *rt_rq);
>>> Â +
>>> Â Â /*
>>> Â Â Â * Update the current task's runtime statistics (provided it is still
>>> Â Â Â * a -deadline task and has not been removed from the dl_rq).
>>> Â @@ -650,11 +652,13 @@ static void update_curr_dl(struct rq *rq
>>> Â Â struct rt_rq *rt_rq = >rt;
>>>
>>> Â Â raw_spin_lock(_rq->rt_runtime_lock);
>>> Â - rt_rq->rt_time += delta_exec;
>>> Â Â /*
>>> Â Â Â * We'll let actual RT tasks worry about the overflow
>>> here, we
>>> Â - * have our own CBS to keep us inline -- see above.
>>> Â + * have our own CBS to keep us inline; only account when RT
>>> Â + * bandwidth is relevant.
>>> Â Â Â */
>>> Â + if (sched_rt_bandwidth_active(rt_rq))
>>> Â + rt_rq->rt_time += delta_exec;
>>> Â Â raw_spin_unlock(_rq->rt_runtime_lock);
>>> Â Â }
>>> Â Â }
>> Â So, I ran some tests with the above and I'd like to share with you what
>> Â I've found. You can find here a trace-cmd trace that should be feeded
>> Â to kernelshark to be able to understand what follows (or feel free to
>> Â reproduce same scenario :)):
>> Â http://retis.sssup.it/~jlelli/traces/trace_rt_time.dat
>>
>> Â Here you have a DL task (4/10) and a while(1) RT task, both running
>> Â inside a rt_bw of 0.5. RT tasks is activated 500ms after DL. As I
>> Â filtered in sched_rt_period_timer(), you can search for time instants
>> Â when the rt_bw is replenished. It is evident that the first time after
>> Â rt timer is activated back (search for start_bandwidth_timer), we can
>> Â eat some bw to FAIR tasks (if any). This is due to the fact that we
>> Â reset rt_bw budget at this time, start decrementing rt_time for both DL
>
> The reset happens when rt_bw replenishment timer fires, after a bit:
>
> Â sched_rt_period_timer <-- __run_hrtimer
Juri, sorry, I forgot to wrote I mean the situation when only one task is on_rq
at every moment.
DL, RT, DL, RT, ...
rt_runtime = n;
rt_period = 2n;
| DL's working, RT's sleeping | RT's working, DL's sleeping | all sleep
|
--|
| (1) duration = n | (2) duration = n | (3)
duration = n | (repeat)
|--|--|---|
| (rt_bw timer is not running) | (rt_bw timer is running)
|
According to the patch, rt_bw timer is working only if we have queued RT task.
In the case above part (1) has no queued RT tasks, so timer is not working.
rt_time is not being increased too.
We have ratio 2/3.
Thanks,
Kirill
>
> Apologies,
>
> - Juri
>
>> Â and RT tasks, throttle RT tasks when rt_time > runtime, but, since DL
>> Â tasks acually executes inside their own server, they don't care about
>> Â rt_bw. Good news is that steady state is ok: keeping track of overruns
>> Â we are able to stop eating bw to other guys.
>>
>> Â My thougths:
>>
>> Â Â - Peter's patch is an easy fix to Kirill's problem (RT tasks were
>> throttled too early);
>> Â Â - something to add to this solution could be to pre-calculate bw of
>> ready DL tasks and subtract it to rt_bw at replenishment time, but
>> it sounds quite awkward, pessimistic, and I'm not sure it is gonna
>> work;
>> Â Â - we are stealing bw to best-effort tasks, and just at the beginning
>> of the transistion, is it
Re: [PATCH 0/9] block: Use pci_enable_msix_range() instead of pci_enable_msix()
On Wed, Feb 19 2014, Alexander Gordeev wrote: > As result of deprecation of MSI-X/MSI enablement functions > pci_enable_msix() and pci_enable_msi_block() all drivers > using these two interfaces need to be updated to use the > new pci_enable_msi_range() and pci_enable_msix_range() > interfaces. Thanks. Applied 3-4, and 6-9 (didn't get the others). -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK
On 02/21/2014 06:18 PM, Tejun Heo wrote: On Fri, Feb 21, 2014 at 06:01:29PM -0500, Peter Hurley wrote: smp_mb__after_unlock_lock() is only for ordering memory operations between two spin-locked sections on either the same lock or by the same task/cpu. Like: i = 1 spin_unlock(lock1) spin_lock(lock2) smp_mb__after_unlock_lock() j = 1 This guarantees that the store to j happens after the store to i. Without it, a cpu can spin_lock(lock2) j = 1 i = 1 spin_unlock(lock1) ; Hmmm? I'm pretty sure that's a full barrier. Local processor is always in order (w.r.t. the compiler). It's a long story but the short version is that Documentation/memory-barriers.txt recently was overhauled to reflect what cpus actually do and what the different archs actually deliver. Turns out that unlock + lock is not guaranteed by all archs to be a full barrier. Thus the smb_mb__after_unlock_lock(). This is now all spelled out in memory-barriers.txt under the sub-heading "IMPLICIT KERNEL MEMORY BARRIERS". Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13 00/99] 3.13.5-stable review
On 02/20/2014 04:51 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.13.5 release. There are 99 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Feb 22 23:51:00 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.13.5-rc1.gz and the diffstat can be found below. thanks, greg k-h Compile tests and boot tests passed. No dmesg regressions: emerg, crit, alert, err are clean. No regressions in warn. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drbd: Fix future possible NULL pointer dereference
On Wed, Feb 19 2014, Philipp Reisner wrote: > From: Andreas Gruenbacher > > Right now every resource has exactly one connection. But we are preparing > for dynamic connections. I.e. in the future thre can be resources without > connections. > > However smatch points this out as 'variable dereferenced before check', > which is correct. > > This issue was introduced in > drbd: get_one_status(): Iterate over resource->devices instead of > connection->peer_devices Applied, thanks. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/82] 3.12.13-stable review
On 02/20/2014 04:51 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.12.13 release. There are 82 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Feb 22 23:50:04 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.13-rc1.gz and the diffstat can be found below. thanks, greg k-h Compile tests and boot tests passed. No dmesg regressions: emerg, crit, alert, err are clean. No regressions in warn. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.4 00/25] 3.4.82-stable review
On 02/20/2014 04:51 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.82 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Feb 22 23:48:32 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.82-rc1.gz and the diffstat can be found below. thanks, greg k-h Compile tests and boot tests passed. No dmesg regressions: emerg, crit, alert, err are clean. No regressions in warn. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.10 00/66] 3.10.32-stable review
On 02/20/2014 04:50 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.32 release. There are 66 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Feb 22 23:48:52 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.32-rc1.gz and the diffstat can be found below. thanks, greg k-h After dropping the iio: max1363: Use devm_regulator_get_optional for optional regulator change: Compile tests and boot tests passed. No dmesg regressions: emerg, crit, alert, err are clean. No regressions in warn. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/4] ntb: Fix leakage of ntb_device::msix_entries[] array
On Fri, Feb 21, 2014 at 04:49:29PM +0100, Alexander Gordeev wrote:
> Signed-off-by: Alexander Gordeev
> Cc: Jon Mason
> Cc: linux-...@vger.kernel.org
Good catch. Applied.
> ---
> drivers/ntb/ntb_hw.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> index 170e8e6..487169dd 100644
> --- a/drivers/ntb/ntb_hw.c
> +++ b/drivers/ntb/ntb_hw.c
> @@ -1281,6 +1281,7 @@ static void ntb_free_interrupts(struct ntb_device *ndev)
> free_irq(msix->vector, >db_cb[i]);
> }
> pci_disable_msix(pdev);
> + kfree(ndev->msix_entries);
> } else {
> free_irq(pdev->irq, ndev);
>
> --
> 1.7.7.6
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] audit: add arch field to seccomp event log
On 14/02/19, Richard Guy Briggs wrote:
> On 14/02/18, Richard Guy Briggs wrote:
> > On 14/02/18, Steve Grubb wrote:
> > > On Tuesday, February 18, 2014 03:50:44 PM Richard Guy Briggs wrote:
> > > > > missing '=' but this isn't what audit_get_context() does... it's
> > > > > crappy naming...I'd think a combo of audit_dummy_context() and
> > > > > current->audit_context would be most appropriate.
> > > >
> > > > Ok. I think I finally understand audit_dummy_context(). Thanks for the
> > > > hint. However, it appears it is not useful in this sitation, since if
> > > > there is an audit_context, even a dummy context, it appears arch is
> > > > filled in.
> > > >
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > @@ -2406,12 +2406,18 @@ void audit_core_dumps(long signr)
> > > > void __audit_seccomp(unsigned long syscall, long signr, int code)
> > > > {
> > > > struct audit_buffer *ab;
> > > > + struct audit_context *context = current->audit_context;
> > > >
> > > > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_SECCOMP);
> > > > if (unlikely(!ab))
> > > > return;
> > > > audit_log_task(ab);
> > > > audit_log_format(ab, " sig=%ld", signr);
> > > > + audit_log_format(ab, " arch=");
> > > > + if (context)
> > > > + audit_log_format(ab, "%x", context->arch);
> > > > + else
> > > > + audit_log_format(ab, "(null)");
> > > > audit_log_format(ab, " syscall=%ld", syscall);
> > > > audit_log_format(ab, " compat=%d", is_compat_task());
> > > > audit_log_format(ab, " ip=0x%lx", KSTK_EIP(current));
> > >
> > > Is there anything that could be passed by the caller that might identify
> > > the
> > > syscall ABI when this call was blocked? '(null)' still makes syscall
> > > number
> > > uninterpretable.
> >
> > This is the way it is done in the existing record that prints a syscall
> > record in audit_log_exit().
> >
> > It is set by the arch-dependent assembler linkage for
> > __audit_syscall_entry() or set by the arch-dependent ptrace code that
> > calls audit_syscall_entry(). In some arches there are a couple of
> > choices.
> >
> >
> > To pass this in to __audit_seccomp() as an arg, I'd have to add that arg
> > to:
> > __audit_seccomp()
> > audit_seccomp()
> > __secure_computing()
> > secure_computing()
> >
> >
> > As you've pointed out in IRC, there is a syscall_get_arch(current, regs)
> > that could be used to get the arch when an audit context is not yet created.
>
> s390x architecture doesn't have it defined. :(
It is defined, but is having trouble finding it...
> > I was just looking for something like that... I am noticing that all
> > arches call a variant of syscall_trace_enter() which first calls
> > secure_computing() [which eventually calls __audit_seccomp()] *before*
> > calling audit_syscall_entry() [which eventually sets context->arch]. So
> > I'm not sure how task->audit_context->arch got set... Perhaps
> > __audit_syscall_entry() should just call syscall_get_arch() instead of
> > lugging it through the stack like it presently does.
> >
> > Is this going to give the same information? (I guess I should be able
> > to answer that question...)
> >
> > > -Steve
> >
> > - RGB
>
> - RGB
- RGB
--
Richard Guy Briggs
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ioat: fix tasklet tear down
On Thu, 20 Feb 2014, Dan Williams wrote: > On Thu, Feb 20, 2014 at 2:30 AM, Thomas Gleixner wrote: > > That's 18 of 30 usage sites. Impressive > > > > We need to poke the relevant maintainers to get this solved. > > > > Maybe also rename tasklet_disable() to tasklet_pause() to make it > clearer "this isn't the tasklet cleanup routine you're looking for"? Indeed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs/bio-integrity: remove duplicate code
On Fri, Feb 21 2014, Gu Zheng wrote: > Most code of function bio_integrity_verify and bio_integrity_generate > is the same, so introduce a help function bio_integrity_generate_verify() > to remove the duplicate code. Thanks, queued up for the next release. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] time: Improve negative offset handling in timekeeping_inject_offset
On Fri, Feb 21, 2014 at 2:54 PM, Thomas Gleixner wrote:
> On Fri, 21 Feb 2014, John Stultz wrote:
>> I fully agree with this, but since the existing interface
>> only accepts #7 style negative timespecs, we have to continue
>> to support that style for this interface.
>>
>> Another possible view is that the rule that the tv_nsec
>> value always be [0,1e9). And that while maybe non-intuitive,
>> the #7 style representations are valid and the existing
>> interface is correct, thus no further change is needed.
>
> We have the requirement all over the place in the kernel to use
> normalized timespecs in the #7 form where: 0 <= tv_nsec < 1e9
>
[snip]
> If you have the 0 <= tv_nsec < 1e9 enforcement, then you catch that
> issue way before the add actually makes the tv_nsec value negative and
> causes some undechifferable wreckage.
>
> Sure you might argue that the requirement is:
>
> -1e9 < tv_nsec < 1e9
>
> but then you need to allow all combinations of signs of tv_sec/tv_nsec
> just for compatibility reasons.
>
> Sure our normalize function can cope with that, but where is the
> point?
>
> We already enforce the 0 <= tv_nsec < 1e9 on all timespec interfaces
> (kernel interal and syscalls), which in turn forces people to use
> timespec_add/sub_ns or timespec_normalize.
Though we also require timespecs to be for positive intervals (at
least from a user-space side), so this case doesn't have a whole bunch
of precedent to follow.
And as an in-kernel counter example, I think the wall_to_monotonic
timespec is represented in {-1, -500} style.
> Why can't the adjtimex folks not handle that? They already have to
> handle the kernel readouts which are in the normalized form. So what's
> the problem to feed their computational value through
> normalize/sub/add whatever before handing it to the kernel.
Having libc handle the translation is indeed another option (one
Richard already brought up in private). It rubs me a little bit the
wrong way as its fairly easy to handle this in kernel and then we
don't have compatability issues depending on what the libc
implementation does.
[snip]
> I really prefer that people use proper helper functions to
> add/sub/normalize timespecs into a single representation instead of
> having to look at a gazillion of permutations of the same unparseable
> crap.
>
> Aside of that, if we allow that for adjtimex, then how do we argue the
> restriction on all other timespec related interfaces?
I'd say the rule that the signs must agree is a good one to start out
with. However, in the case with this interface, we allow for the
awkward {-3,500} style values to be compatible with earlier releases.
But yes, we can just leave it as is, and it is a bit academic. But
mostly for me this is just about making the interface a bit more
intuitive when working with negative relative intervals, and maybe
more importantly making clear the precedent should any other userspace
interface do something similar.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
printk and kdb - dev_ not trapped/forwarded
dev_ output does not use printk() but directly calls vprintk_emit(). kdb only traps direct printk() calls. So, kdb hasn't emitted any dev_ or netdev_ output since structured logging and vprintk_emit() was introduced a couple of years ago. It seems no one has cared. Maybe the kdb handling should be removed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 2/5] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent
On Friday, February 21, 2014 06:24:24 PM Catalin Marinas wrote: > Hi Rafael, > > On Wed, Feb 19, 2014 at 01:50:22AM +0100, Rafael J. Wysocki wrote: > > On Wednesday, February 19, 2014 12:23:55 AM Hanjun Guo wrote: > > > _PDC related stuff in processor_core.c is little bit X86/IA64 dependent, > > > rework the code to make it more arch-independent, no functional change > > > in this patch. > > > > > > Signed-off-by: Hanjun Guo > > > Signed-off-by: Graeme Gregory > > > > I've queued up patches [1,3-5/5] from this series for 3.15 (modulo changelog > > modifications), but this one should be CCed to the x86 and ia64 maintainers. > > Thanks for taking these patches. I would however hold onto patch 3/5 as > this is still under discussion. Basically for patches specific to ARM > ACPI I would really like to see more acks before being merged as that's > a new thing for us. OK, I'll drop [3/5] for now, then. I'm wondering, though, whose ACKs I should be waiting for before applying those patches? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] ps3-vuart: don't use PREPARE_WORK
Hi, On Thu, 2014-02-20 at 15:44 -0500, Tejun Heo wrote: > ps3_vuart wasn't overriding the work item with multiple work functions > but was using NULL for INIT_WORK() and then single PREPARE_WORK() to > set the work function. We can simply invoke INIT_WORK() with the work > function and remove the PREPARE_WORK() usage. > > It would probably be best to route this with other related updates > through the workqueue tree. I tested this on ps3 (DECR-1400) and it seems to work OK. Please queue with your other workqueue changes. Thanks! Acked-by: Geoff Levand -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 10/33] iommu, irq: Allocate irq_desc for dmar_msi with local node
On Thu, Feb 20, 2014 at 11:43 PM, Jiang Liu wrote: > > > On 2014/1/3 8:05, Yinghai Lu wrote: >> iommu irq's irq_desc should be on local node ram. >> >> Fix the return value checking problem. >> create_irq() will return -1 when fail to allocate. >> create_irq_nr() will return 0 when fail to allocate. >> here only check !irq, so need to change it to use create_irq_nr instead. >> >> -v2: According to Sebastian, add cc to stable. >> >> Signed-off-by: Yinghai Lu >> Cc: Joerg Roedel >> Cc: Donald Dutile >> Acked-by: Donald Dutile >> Cc: Sebastian Andrzej Siewior >> Cc: sta...@vger.kernel.org >> --- >> drivers/iommu/dmar.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c >> index 8b452c9..f4eaa50 100644 >> --- a/drivers/iommu/dmar.c >> +++ b/drivers/iommu/dmar.c >> @@ -1277,7 +1277,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu) >> if (iommu->irq) >> return 0; >> >> - irq = create_irq(); >> + irq = create_irq_nr(0, iommu->node); > Hi Yinghai, > How about create_irq_nrq(1, iommu->node) here to clearly state > that 0 is not a valid irq number for dmar here? Should be the same. that 0 or 1 will be from in __create_irqs(). And we have if (from < nr_irqs_gsi) from = nr_irqs_gsi; in __create_irqs(). Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK
On Fri, Feb 21, 2014 at 06:01:29PM -0500, Peter Hurley wrote: > smp_mb__after_unlock_lock() is only for ordering memory operations > between two spin-locked sections on either the same lock or by > the same task/cpu. Like: > >i = 1 >spin_unlock(lock1) >spin_lock(lock2) >smp_mb__after_unlock_lock() >j = 1 > > This guarantees that the store to j happens after the store to i. > Without it, a cpu can > >spin_lock(lock2) >j = 1 >i = 1 >spin_unlock(lock1) Hmmm? I'm pretty sure that's a full barrier. Local processor is always in order (w.r.t. the compiler). 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 1/1] ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
* Mugunthan V N [140216 23:56]: > From: Santosh Shilimkar > > for non SMP build, NR_CPUS is 1 and hence the code complains with below > warnings. > > arch/arm/mach-omap2/cpuidle44xx.c:207:8: warning: array subscript is above > array bounds [-Warray-bounds] > arch/arm/mach-omap2/cpuidle44xx.c:212:11: warning: array subscript is above > array bounds [-Warray-bounds] > > Kill it by making array size fixed. > > Acked-by: Nishanth Menon > Signed-off-by: Santosh Shilimkar > Signed-off-by: Mugunthan V N Thanks applying into omap-for-v3.14/fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/66] 3.10.32-stable review
On 02/21/2014 11:01 AM, Greg Kroah-Hartman wrote: On Thu, Feb 20, 2014 at 09:09:48PM -0800, Guenter Roeck wrote: On 02/20/2014 03:50 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.32 release. There are 66 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Feb 22 23:48:52 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 111 skipped: 4 fail: 11 qemu tests all passed. Results are not as expected. New failures are due to Guenter Roeck iio: max1363: Use devm_regulator_get_optional for optional regulator [Oops] This patch is now dropped, thanks. Much better: total: 126 pass: 121 skipped: 4 fail: 1 with all qemu tests passed. So we are back to the expected results. 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] NTB: Fix typo in setting one translation register
On Fri, Feb 21, 2014 at 08:07:21AM -0800, Roland Dreier wrote: > From: Roland Dreier > > In the code for Xeon devices in back-to-back mode with xeon_errata_workaround > disabled, the downstream device puts the wrong value in SNB_B2B_XLAT_OFFSETL > (SNB_MBAR01_DSD_ADDR vs. SNB_MBAR01_USD_ADDR). > > This was spotted while reading code, since the typo has no practical effect, > at least for now: the low 32 bits of both constants are actually identical > anyway. However, it's clearer and safer to use the right name. Good catch. Applied. > > Signed-off-by: Roland Dreier > --- > drivers/ntb/ntb_hw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c > index 170e8e60cdb7..2774d356b689 100644 > --- a/drivers/ntb/ntb_hw.c > +++ b/drivers/ntb/ntb_hw.c > @@ -785,7 +785,7 @@ static int ntb_xeon_setup(struct ntb_device *ndev) > /* B2B_XLAT_OFFSET is a 64bit register, but can >* only take 32bit writes >*/ > - writel(SNB_MBAR01_DSD_ADDR & 0x, > + writel(SNB_MBAR01_USD_ADDR & 0x, > ndev->reg_base + SNB_B2B_XLAT_OFFSETL); > writel(SNB_MBAR01_USD_ADDR >> 32, > ndev->reg_base + SNB_B2B_XLAT_OFFSETU); > -- > 1.9.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: OMAP2+: Add support for thumb mode on DT booted N900
* Sebastian Reichel [140217 13:33]: > Without enabling the workaround for ARM errata 430973 thumb > compiled userland crashes randomly on the Nokia N900. > > Signed-off-by: Sebastian Reichel > Reviewed-by: Pavel Machek > --- > Hi, > > This is PATCHv2 for the thumb errata workaround for N900 DT > boot, which should go into 3.14-rc. > > Changes since PATCHv1: > * Add Reviewed-By: Pavel Machek > * Add more verbose warning about the errata as suggested by Pavel > > I did not increase the verbose level, since the next higher verbose > level is pr_err and the message is not an error. > > I think it would make sense to update the Kconfig entry for the errata to > enable the workaround by default for the Nokia N900. That should be done in > its own patch, though. > > Apart from that it would be nice if errata workaround could be enabled > via DeviceTree instead of kernel configuration. This will require some > discussion though, so I think we should start with this patch for now. Thanks applying into omap-for-v3.14/fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kaslr: randomize module base load address
On 02/21/2014 01:27 PM, Andrew Morton wrote: > On Fri, 21 Feb 2014 13:18:26 -0800 "H. Peter Anvin" wrote: > >> On 02/21/2014 01:15 PM, Andrew Morton wrote: I've been slapped down for adding more config options in the past, and I think it's unlikely that people using CONFIG_RANDOMIZE_BASE won't want the modules base randomized too. I think this is a safe default, but if you see it as a requirement, I can change it. >>> >>> I think there were issues with some embedded systems where it's >>> hard/impossible to provide/alter boot parameters. >>> >> >> We now allow kernel parameters to be compiled into the kernel image for >> that reason. > > We do? What's that Kconfig variable called? > CONFIG_CMDLINE and CONFIG_CMDLINE_OVERRIDE. They seem to be x86-specific at this time, although I think some other arches have similar hacks. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK
On 02/21/2014 11:57 AM, Tejun Heo wrote: Yo, On Fri, Feb 21, 2014 at 11:53:46AM -0500, Peter Hurley wrote: Ok, I can do that. But AFAIK it'll have to be an smp_rmb(); there is no mb__after unlock. We do have smp_mb__after_unlock_lock(). [ After thinking about it some, I don't think preventing speculative writes before clearing PENDING if useful or necessary, so that's why I'm suggesting only the rmb. ] But smp_mb__after_unlock_lock() would be cheaper on most popular archs, I think. smp_mb__after_unlock_lock() is only for ordering memory operations between two spin-locked sections on either the same lock or by the same task/cpu. Like: i = 1 spin_unlock(lock1) spin_lock(lock2) smp_mb__after_unlock_lock() j = 1 This guarantees that the store to j happens after the store to i. Without it, a cpu can spin_lock(lock2) j = 1 i = 1 spin_unlock(lock1) Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xfs: fixes for 3.14-rc3
Hi Linus, This is the first pull request I've had to do for you, so I'm still sorting things out. The reason I'm sending this and not Ben should be obvious from the first commit below - SGI has stepped down from the XFS maintainership role. As such, I'd like to take another opportunity to thank them for their many years of effort maintaining XFS and supporting the XFS community that they developed from the ground up. So I haven't had time to work things like signed tags into my workflows yet, so this is just a repo branch I'm asking you to pull from. And yes, I named the branch -rc4 because I wanted the fixes in -rc4, not because the branch was for merging into -rc3. Probably not right, either. Anyway, I should have everything sorted out by the time the next merge window comes around. If there's anything that you don't like in the pull req, feel free to flame me unmercifully. The changes are fixes for recent regressions and important thinkos in verification code: - a log vector buffer alignment issue on ia32 - timestamps on truncate got mangled - primary superblock CRC validation fixes and error message sanitisation Cheers, Dave. The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://oss.sgi.com/xfs/xfs.git xfs-fixes-for-3.14-rc4 for you to fetch changes up to 5ef11eb0700f806c4671ba33e5befa784a2f70ef: xfs: limit superblock corruption errors to actual corruption (2014-02-19 15:39:35 +1100) Ben Myers (1): MAINTAINERS: SGI no longer maintaining XFS Christoph Hellwig (1): xfs: ensure correct timestamp updates from truncate Dave Chinner (1): xfs: ensure correct log item buffer alignment Eric Sandeen (3): xfs: xfs_sb_read_verify() doesn't flag bad crcs on primary sb xfs: skip verification on initial "guess" superblock read xfs: limit superblock corruption errors to actual corruption MAINTAINERS |1 - fs/xfs/xfs_iops.c| 16 fs/xfs/xfs_log_cil.c | 19 +++ fs/xfs/xfs_mount.c | 24 fs/xfs/xfs_sb.c | 10 -- 5 files changed, 43 insertions(+), 27 deletions(-) -- Dave Chinner da...@fromorbit.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/
Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option
> But, like I said, I'm not sure we'd ever be able to totally remove it > because of backwards compatibility, but the point is that nobody would > have to use it anymore as a hack for 1GB. Again it's a perfectly fine and widely used interface. Any talk of removing it is wrong. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] time: Improve negative offset handling in timekeeping_inject_offset
On Fri, 21 Feb 2014, John Stultz wrote: > I fully agree with this, but since the existing interface > only accepts #7 style negative timespecs, we have to continue > to support that style for this interface. > > Another possible view is that the rule that the tv_nsec > value always be [0,1e9). And that while maybe non-intuitive, > the #7 style representations are valid and the existing > interface is correct, thus no further change is needed. We have the requirement all over the place in the kernel to use normalized timespecs in the #7 form where: 0 <= tv_nsec < 1e9 To be honest, it's not the prettiest thing, but timespec is not pretty to begin with. And there is a good reason to be strict about that. Assume the following code: t.tv_nsec += interval_ns; fn(); If you do not validate that, then there is no chance to yell at the abuser early. If you have the 0 <= tv_nsec < 1e9 enforcement, then you catch that issue way before the add actually makes the tv_nsec value negative and causes some undechifferable wreckage. Sure you might argue that the requirement is: -1e9 < tv_nsec < 1e9 but then you need to allow all combinations of signs of tv_sec/tv_nsec just for compatibility reasons. Sure our normalize function can cope with that, but where is the point? We already enforce the 0 <= tv_nsec < 1e9 on all timespec interfaces (kernel interal and syscalls), which in turn forces people to use timespec_add/sub_ns or timespec_normalize. Why can't the adjtimex folks not handle that? They already have to handle the kernel readouts which are in the normalized form. So what's the problem to feed their computational value through normalize/sub/add whatever before handing it to the kernel. That's a pure academic problem, just because people think that -5, -321654987 is so much more readable than -6, 678345013 Now if we allow that we also need to allow 5, -987654321 versus 4, 12345679 It's all unreadable in one way or the other. I really prefer that people use proper helper functions to add/sub/normalize timespecs into a single representation instead of having to look at a gazillion of permutations of the same unparseable crap. Aside of that, if we allow that for adjtimex, then how do we argue the restriction on all other timespec related interfaces? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13 35/99] tty: Set correct tty name in active sysfs attribute
Hi,
On Fri, Feb 21, 2014 at 11:01 AM, Kay Sievers wrote:
> Why did the tty0 change to tty1 now? That doesn't look like a "driver
> name" vs. "device name" issue?
I don't know if it's intentional, but the patch does:
+ int index = cs[i]->index;
...
+ driver = cs[i]->device(cs[i], );
which will presumably change the index from 0 to 1 because of this code:
static struct tty_driver *vt_console_device(struct console *c, int *index)
{
*index = c->index ? c->index-1 : fg_console;
return console_driver;
}
At least that's what it looks like is causing the problem from
browsing through the source a bit.
--Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Add device id for Thrustmaster GPX Gamepad for joystick/xpad.c driver
Signed-off-by: Marcin Lulek
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 603fe0d..b94668f 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -124,6 +124,7 @@ static const struct xpad_device {
{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX360W },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
+ { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360
},
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] serial: 8250_pci: fix support for MosChip 98xx boards
On Fri, Feb 21, 2014 at 02:46:17PM -0800, Ira W. Snyder wrote:
> From: "Ira W. Snyder"
>
> Commit 7808edcd306f22aeb23775d34e70b7fa2f58b852 "Basic support for
> Moschip 9900 family I/O chips" broke support for the 98xx boards. This
> is due to a missing check for the 99xx family inside the newly added
> pci_netmos_9900_setup() function, which is now used for all boards in
> the Moschip family.
>
> The code for skipping BARs is incorrect for the 98xx boards. Using it
> causes two serial ports to be left undetected on my 9865 board.
>
> By checking for the 99xx boards and using the new code exclusively for
> them, all of my serial ports are now detected.
>
> Signed-off-by: Ira W. Snyder
> ---
>
> Here is the lspci output for my 9865 board. On the 05:00.2 device, the
> middle two serial ports (I/O ports 0x1010 and 0x1008) are left unused
> and undetected without this patch.
>
> After the patch, they work perfectly.
>
> 05:00.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
> Multi-I/O Controller (prog-if 02 [16550])
> Subsystem: Device a000:1000
> Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 21
> I/O ports at 1028 [size=8]
> Memory at e0104000 (32-bit, non-prefetchable) [size=4K]
> Memory at e0103000 (32-bit, non-prefetchable) [size=4K]
> Capabilities:
> Kernel driver in use: serial
> Kernel modules: parport_pc
>
> 05:00.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
> Multi-I/O Controller (prog-if 02 [16550])
> Subsystem: Device a000:1000
> Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 22
> I/O ports at 1020 [size=8]
> Memory at e0102000 (32-bit, non-prefetchable) [size=4K]
> Memory at e0101000 (32-bit, non-prefetchable) [size=4K]
> Capabilities:
> Kernel driver in use: serial
> Kernel modules: parport_pc
>
> 05:00.2 Communication controller: MosChip Semiconductor Technology Ltd. PCI
> 9865 Multi-I/O Controller
> Subsystem: Device a000:3004
> Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 23
> I/O ports at 1018 [size=8]
> I/O ports at 1010 [size=8]
> I/O ports at 1008 [size=8]
> I/O ports at 1000 [size=8]
> Memory at e010 (32-bit, non-prefetchable) [size=4K]
> Capabilities:
> Kernel driver in use: serial
>
> drivers/tty/serial/8250/8250_pci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_pci.c
> b/drivers/tty/serial/8250/8250_pci.c
> index 50228eed3b6f..374551f196c5 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -783,7 +783,8 @@ static int pci_netmos_9900_setup(struct serial_private
> *priv,
> {
> unsigned int bar;
>
> - if ((priv->dev->subsystem_device & 0xff00) == 0x3000) {
> + if ((priv->dev->subsystem_device & 0xff00) == 0x3000 &&
> + (priv->dev->device & 0xff00) == 0x9900) {
> /* netmos apparently orders BARs by datasheet layout, so serial
>* ports get BARs 0 and 3 (or 1 and 4 for memmapped)
>*/
> --
> 1.8.3.2
>
Adding some CC's that were missed the first time. Greg's email address
has changed.
Apologies,
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] capability: Use current logging styles
Quoting Joe Perches (j...@perches.com):
> Prefix logging output with "capability: " via pr_fmt.
> Convert printks to pr_.
> Use pr__once instead of guard flags.
> Coalesce formats.
>
> Signed-off-by: Joe Perches
Thanks.
Acked-by: Serge E. Hallyn
> ---
> kernel/capability.c | 29 ++---
> 1 file changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 34019c5..a8d63df 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -7,6 +7,8 @@
> * 30 May 2002: Cleanup, Robert M. Love
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include
> #include
> #include
> @@ -42,15 +44,10 @@ __setup("no_file_caps", file_caps_disable);
>
> static void warn_legacy_capability_use(void)
> {
> - static int warned;
> - if (!warned) {
> - char name[sizeof(current->comm)];
> -
> - printk(KERN_INFO "warning: `%s' uses 32-bit capabilities"
> -" (legacy support in use)\n",
> -get_task_comm(name, current));
> - warned = 1;
> - }
> + char name[sizeof(current->comm)];
> +
> + pr_info_once("warning: `%s' uses 32-bit capabilities (legacy support in
> use)\n",
> + get_task_comm(name, current));
> }
>
> /*
> @@ -71,16 +68,10 @@ static void warn_legacy_capability_use(void)
>
> static void warn_deprecated_v2(void)
> {
> - static int warned;
> + char name[sizeof(current->comm)];
>
> - if (!warned) {
> - char name[sizeof(current->comm)];
> -
> - printk(KERN_INFO "warning: `%s' uses deprecated v2"
> -" capabilities in a way that may be insecure.\n",
> -get_task_comm(name, current));
> - warned = 1;
> - }
> + pr_info_once("warning: `%s' uses deprecated v2 capabilities in a way
> that may be insecure\n",
> + get_task_comm(name, current));
> }
>
> /*
> @@ -380,7 +371,7 @@ bool has_capability_noaudit(struct task_struct *t, int
> cap)
> bool ns_capable(struct user_namespace *ns, int cap)
> {
> if (unlikely(!cap_valid(cap))) {
> - printk(KERN_CRIT "capable() called with invalid cap=%u\n", cap);
> + pr_crit("capable() called with invalid cap=%u\n", cap);
> BUG();
> }
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] afs: afs_alloc_inode: use kmem_cache_zalloc
Andrew Morton wrote:
> > - * allocate an AFS inode struct from our slab cache
> > + * allocate an AFS inode struct
> > */
> > static struct inode *afs_alloc_inode(struct super_block *sb)
> > {
>
> err, this was obviously a product of senility.
My comment, or your comment on my comment?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] integrator base patches for v3.15
On Thu, Feb 13, 2014 at 01:35:38PM +0100, Linus Walleij wrote: > Hi ARM SoC folks, > > this is a set of patches I have sent for review and failed to get > ACKs from the proper subsystem maintainers after repeated > pings. However I now need to have this rotated in linux-next > as a base for multiplatform, so please pull it in, it is all ARM > drivers anyway. Russell pointed out some things and these > have been fixed and iterated in this series. > > Yours, > Linus Walleij > > The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed: > > Linux 3.14-rc2 (2014-02-09 18:15:47 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git > tags/integrator-for-v3.15-1 > > for you to fetch changes up to 29525484cd2524a31ee0924831ab43b46ea6ebe1: > > ARM: integrator: select GPIO block (2014-02-13 11:21:37 +0100) These patches are a little all over the place -- some is new dt bindings, some are driver cleanups, etc. I ended up merging it into next/drivers since that's what the bulk of the changes were in this time. So, pulled. Thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mm: kernel BUG at mm/huge_memory.c:1371!
Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the following (now with pretty line numbers!) spew: [ 746.125099] kernel BUG at mm/huge_memory.c:1371! [ 746.125775] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 746.126774] Dumping ftrace buffer: [ 746.127484](ftrace buffer empty) [ 746.127781] Modules linked in: [ 746.128358] CPU: 2 PID: 19816 Comm: trinity-c127 Tainted: GW 3.14.0-rc3-next-20140221-sasha-8-g0e660cf-dirty #114 [ 746.130196] task: 8803a7cc3000 ti: 8803a7f1c000 task.ti: 8803a7f1c000 [ 746.130317] RIP: 0010:[] [] zap_huge_pmd+0x17a/0x200 [ 746.130317] RSP: 0018:8803a7f1dca8 EFLAGS: 00010246 [ 746.130317] RAX: 8801ab4ac000 RBX: 8803a7f1ddd8 RCX: 002e [ 746.130317] RDX: RSI: 8803a7cc3d00 RDI: 0172c000 [ 746.130317] RBP: 8803a7f1dce8 R08: R09: [ 746.130317] R10: 0001 R11: 0001 R12: ea0006a8fa00 [ 746.130317] R13: ea0005cb R14: 7f784f80 R15: 7f785750bfff [ 746.130317] FS: 7f785afbc700() GS:8801abc0() knlGS: [ 746.130317] CS: 0010 DS: ES: CR0: 8005003b [ 746.130317] CR2: 0010 CR3: 0003a9739000 CR4: 06e0 [ 746.130317] DR0: 00693000 DR1: DR2: [ 746.130317] DR3: DR6: 0ff0 DR7: 0600 [ 746.130317] Stack: [ 746.130317] 04de 8803a9777390 8803a7f1dce8 8803a2afd3e0 [ 746.130317] 7f784f80 7f785750c000 8803a7f1ddd8 7f785750bfff [ 746.130317] 8803a7f1dd78 81285536 001d8500 7f784fa0 [ 746.130317] Call Trace: [ 746.130317] [] unmap_page_range+0x2c6/0x410 [ 746.130317] [] unmap_single_vma+0xf1/0x110 [ 746.130317] [] zap_page_range+0x121/0x170 [ 746.130317] [] madvise_vma+0x180/0x1c0 [ 746.130317] [] SyS_madvise+0x17e/0x250 [ 746.130317] [] tracesys+0xdd/0xe2 [ 746.152464] Code: 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 81 80 60 03 00 00 00 fe ff ff 49 8b 45 00 f6 c4 40 75 18 31 f6 4c 89 ef e8 26 29 f9 ff <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 48 8b 03 f0 48 ff 48 [ 746.152464] RIP [] zap_huge_pmd+0x17a/0x200 [ 746.152464] RSP Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] ath9k: Use static const
Trivially reduces text size too.
$ size drivers/net/wireless/ath/ath9k/debug.o*
textdata bss dec hex filename
3443625285128 42092a46c
drivers/net/wireless/ath/ath9k/debug.o.new
3446425285128 42120a488
drivers/net/wireless/ath/ath9k/debug.o.old
Signed-off-by: Joe Perches
---
drivers/net/wireless/ath/ath9k/debug.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index ab7264c..9131175 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -135,7 +135,8 @@ static ssize_t read_file_ani(struct file *file, char __user
*user_buf,
struct ath_softc *sc = file->private_data;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ath_hw *ah = sc->sc_ah;
- unsigned int len = 0, size = 1024;
+ unsigned int len = 0;
+ const unsigned int size = 1024;
ssize_t retval = 0;
char *buf;
@@ -307,13 +308,13 @@ static ssize_t read_file_antenna_diversity(struct file
*file,
struct ath_antenna_stats *as_main =
>debug.stats.ant_stats[ANT_MAIN];
struct ath_antenna_stats *as_alt = >debug.stats.ant_stats[ANT_ALT];
struct ath_hw_antcomb_conf div_ant_conf;
- unsigned int len = 0, size = 1024;
+ unsigned int len = 0;
+ const unsigned int size = 1024;
ssize_t retval = 0;
char *buf;
- char *lna_conf_str[4] = {"LNA1_MINUS_LNA2",
-"LNA2",
-"LNA1",
-"LNA1_PLUS_LNA2"};
+ static const char *lna_conf_str[4] = {
+ "LNA1_MINUS_LNA2", "LNA2", "LNA1", "LNA1_PLUS_LNA2"
+ };
buf = kzalloc(size, GFP_KERNEL);
if (buf == NULL)
@@ -716,10 +717,13 @@ static ssize_t read_file_queues(struct file *file, char
__user *user_buf,
struct ath_softc *sc = file->private_data;
struct ath_txq *txq;
char *buf;
- unsigned int len = 0, size = 1024;
+ unsigned int len = 0;
+ const unsigned int size = 1024;
ssize_t retval = 0;
int i;
- char *qname[4] = {"VO", "VI", "BE", "BK"};
+ static const char *qname[4] = {
+ "VO", "VI", "BE", "BK"
+ };
buf = kzalloc(size, GFP_KERNEL);
if (buf == NULL)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] serial: 8250_pci: fix support for MosChip 98xx boards
From: "Ira W. Snyder"
Commit 7808edcd306f22aeb23775d34e70b7fa2f58b852 "Basic support for
Moschip 9900 family I/O chips" broke support for the 98xx boards. This
is due to a missing check for the 99xx family inside the newly added
pci_netmos_9900_setup() function, which is now used for all boards in
the Moschip family.
The code for skipping BARs is incorrect for the 98xx boards. Using it
causes two serial ports to be left undetected on my 9865 board.
By checking for the 99xx boards and using the new code exclusively for
them, all of my serial ports are now detected.
Signed-off-by: Ira W. Snyder
---
Here is the lspci output for my 9865 board. On the 05:00.2 device, the
middle two serial ports (I/O ports 0x1010 and 0x1008) are left unused
and undetected without this patch.
After the patch, they work perfectly.
05:00.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
Multi-I/O Controller (prog-if 02 [16550])
Subsystem: Device a000:1000
Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 21
I/O ports at 1028 [size=8]
Memory at e0104000 (32-bit, non-prefetchable) [size=4K]
Memory at e0103000 (32-bit, non-prefetchable) [size=4K]
Capabilities:
Kernel driver in use: serial
Kernel modules: parport_pc
05:00.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
Multi-I/O Controller (prog-if 02 [16550])
Subsystem: Device a000:1000
Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 22
I/O ports at 1020 [size=8]
Memory at e0102000 (32-bit, non-prefetchable) [size=4K]
Memory at e0101000 (32-bit, non-prefetchable) [size=4K]
Capabilities:
Kernel driver in use: serial
Kernel modules: parport_pc
05:00.2 Communication controller: MosChip Semiconductor Technology Ltd. PCI
9865 Multi-I/O Controller
Subsystem: Device a000:3004
Flags: bus master, fast Back2Back, medium devsel, latency 32, IRQ 23
I/O ports at 1018 [size=8]
I/O ports at 1010 [size=8]
I/O ports at 1008 [size=8]
I/O ports at 1000 [size=8]
Memory at e010 (32-bit, non-prefetchable) [size=4K]
Capabilities:
Kernel driver in use: serial
drivers/tty/serial/8250/8250_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 50228eed3b6f..374551f196c5 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -783,7 +783,8 @@ static int pci_netmos_9900_setup(struct serial_private
*priv,
{
unsigned int bar;
- if ((priv->dev->subsystem_device & 0xff00) == 0x3000) {
+ if ((priv->dev->subsystem_device & 0xff00) == 0x3000 &&
+ (priv->dev->device & 0xff00) == 0x9900) {
/* netmos apparently orders BARs by datasheet layout, so serial
* ports get BARs 0 and 3 (or 1 and 4 for memmapped)
*/
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option
On Fri, 21 Feb 2014, Andi Kleen wrote: > > > 2) it improves the kernel command line interface from incomplete > > > (lacking the ability to specify node<->page correlation), to > > > a complete interface. > > > > > > > If GB hugepages can be allocated dynamically, I really think we should be > > able to remove hugepagesz= entirely for x86 after a few years of > > supporting it for backwards compatibility, even though Linus has insisted > > That doesn't make any sense. Why break a perfectly fine interface? > I think doing hugepagesz= and not default_hugepagesz= is more of a hack just because we lack support for dynamically allocating some class of hugepage sizes and this is the only way to currently do it; if we had support for doing it at runtime then that hack probably isn't needed. You would still be able to do default_hugepagesz=1G and allocate a ton of them when fragmentation is a concern and it can only truly be done at boot. Even then, with such a large size it doesn't seem absolutely necessary since you'd either be (a) oom as a result of all those hugepages or (b) there would be enough memory for initscripts to do this at runtime, this isn't the case with 2MB. But, like I said, I'm not sure we'd ever be able to totally remove it because of backwards compatibility, but the point is that nobody would have to use it anymore as a hack for 1GB. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
