Re: [PATCH] clk: Make the generic clock API available by default
Around Tue 28 Aug 2012 13:35:04 -0700 or thereabout, Mark Brown wrote: > Rather than requiring platforms to select the generic clock API to make > it available make the API available as a user selectable option unless the > user either selects HAVE_CUSTOM_CLK (if they have their own implementation) > or selects COMMON_CLK (if they depend on the generic implementation). > > All current architectures that HAVE_CLK but don't use the common clock > framework have selects of HAVE_CUSTOM_CLK added. > > This allows drivers to use the generic API on platforms which have no need > for the clock API at platform level. > > Signed-off-by: Mark Brown > --- > > This depends on having one of the patches I've sent adding a generic > clkdev.h added merged - Arnd was expecting to merge one of those, there > was just the lack of clarity about the most practical Kbuild hookup. > > arch/arm/Kconfig| 12 > arch/avr32/Kconfig |1 + For the AVR32 related changes Acked-by: Hans-Christian Egtvedt -- mvh Hans-Christian Egtvedt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND] dma: tegra: add const to of_device_id.data's structure
The member "data" of structure of_device_id is changed to const
pointer. Hence initializing this with const type data.
This will fix the compilation warning like
drivers/dma/tegra20-apb-dma.c:1217:9: warning: assignment discards 'const'
qualifier from
pointer target type [enabled by default]
This warning came after the change
-
commit 98d7bbb9929bcc14e11ac8a55245a4f2dc174e17
Author: Uwe Kleine-König
of: add const to struct *of_device_id.data
-
Signed-off-by: Laxman Dewangan
Acked-by: Stephen Warren
Acked-by: Vinod Koul
---
Resending patch to Uwe and adding ack from Stephen and Vinod.
Fix typo in description.
drivers/dma/tegra20-apb-dma.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 24acd71..09a15ff 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -201,7 +201,7 @@ struct tegra_dma {
struct clk *dma_clk;
spinlock_t global_lock;
void __iomem*base_addr;
- struct tegra_dma_chip_data *chip_data;
+ const struct tegra_dma_chip_data*chip_data;
/* Some register need to be cache before suspend */
u32 reg_gen;
@@ -1173,14 +1173,14 @@ static void tegra_dma_free_chan_resources(struct
dma_chan *dc)
}
/* Tegra20 specific DMA controller information */
-static struct tegra_dma_chip_data tegra20_dma_chip_data = {
+static const struct tegra_dma_chip_data tegra20_dma_chip_data = {
.nr_channels= 16,
.max_dma_count = 1024UL * 64,
};
#if defined(CONFIG_OF)
/* Tegra30 specific DMA controller information */
-static struct tegra_dma_chip_data tegra30_dma_chip_data = {
+static const struct tegra_dma_chip_data tegra30_dma_chip_data = {
.nr_channels= 32,
.max_dma_count = 1024UL * 64,
};
@@ -1204,7 +1204,7 @@ static int __devinit tegra_dma_probe(struct
platform_device *pdev)
struct tegra_dma *tdma;
int ret;
int i;
- struct tegra_dma_chip_data *cdata = NULL;
+ const struct tegra_dma_chip_data *cdata = NULL;
if (pdev->dev.of_node) {
const struct of_device_id *match;
--
1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] mmc: card: Skip secure option for MoviNAND.
Need to check your mail setting.
On 08/29/2012 02:04 PM, IAN CHEN wrote:
> For several MoviNAND, there are some known issue with secure option.
> For these specific MoviNAND device, we skip secure option.
>
> You could refer this discussion in XDA developers.
> http://forum.xda-developers.com/showthread.php?t=1644364
> https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
>
> Signed-off-by: Ian Chen
> Reviewed-by: Namjae Jeon
> Acked-by: Jaehoon Chung
> Reviewed-by: Linus Walleij
> ---
> drivers/mmc/card/block.c | 24 +++-
> include/linux/mmc/card.h |1 +
> 2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index f1c84de..0377885 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1411,7 +1411,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
> struct request *req)
Line wrap.?
> /* complete ongoing async transfer before issuing discard */
> if (card->host->areq)
> mmc_blk_issue_rw_rq(mq, NULL);
> - if (req->cmd_flags & REQ_SECURE)
> + if (req->cmd_flags & REQ_SECURE &&
> + !(card->quirks & MMC_QUIRK_SEC_ERASE_TRIM_BROKEN))
> ret = mmc_blk_issue_secdiscard_rq(mq, req);
> else
> ret = mmc_blk_issue_discard_rq(mq, req);
> @@ -1716,6 +1717,7 @@ force_ro_fail:
> #define CID_MANFID_SANDISK 0x2
> #define CID_MANFID_TOSHIBA 0x11
> #define CID_MANFID_MICRON0x13
> +#define CID_MANFID_SAMSUNG 0x15
>
> static const struct mmc_fixup blk_fixups[] =
> {
> @@ -1752,6 +1754,26 @@ static const struct mmc_fixup blk_fixups[] =
> MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
> MMC_QUIRK_LONG_READ_TIME),
>
> + /*
> + * Some issue about secure erase/secure trim for Samsung MoviNAND
> + */
> + MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> + MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> +
> END_FIXUP
> };
>
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 111aca5..4b27f9f 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -239,6 +239,7 @@ struct mmc_card {
> #define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for
> regular
> multiblock */
here..
> #define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8)/* Avoid sending 512
> bytes in */
Also
> #define MMC_QUIRK_LONG_READ_TIME (1<<9) /* Data read time > CSD
> says */
> +#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10) /* Skip secure for
> erase/trim */
Also line wrap?
> /* byte mode */
> unsigned intpoweroff_notify_state; /* eMMC4.5 notify feature */
> #define MMC_NO_POWER_NOTIFICATION0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb: tegra: moving phy driver into drivers directory
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, August 28, 2012 7:37 PM
> To: Venu Byravarasu
> Cc: ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk;
> st...@rowland.harvard.edu; gre...@linuxfoundation.org; ba...@ti.com;
> linux-kernel@vger.kernel.org; linux-te...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: tegra: moving phy driver into drivers directory
>
> On 08/28/2012 02:32 AM, Venu Byravarasu wrote:
> > In order to keep up with the USB driver files organization,
> > moving USB phy driver from mach-tegra to drivers/USB directory.
> >
> > Signed-off-by: Venu Byravarasu
>
> > diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-
> tegra/devices.c
>
> > -struct tegra_ulpi_config tegra_ehci2_ulpi_phy_config = {
> > - .reset_gpio = -1,
> > - .clk = "cdev2",
> > -};
> > -
> > struct tegra_ehci_platform_data tegra_ehci1_pdata = {
> > .operating_mode = TEGRA_USB_OTG,
> > .power_down_on_bus_suspend = 1,
> > @@ -450,7 +444,7 @@ struct tegra_ehci_platform_data tegra_ehci1_pdata
> = {
> > };
> >
> > struct tegra_ehci_platform_data tegra_ehci2_pdata = {
> > - .phy_config = _ehci2_ulpi_phy_config,
> > + .phy_config = NULL,
>
> The PHY driver checks that field isn't NULL, and fails if it is:
>
> > struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int
> instance,
> > void __iomem *regs, void *config, enum tegra_usb_phy_mode
> phy_mode)
> > {
> ...
> > phy->config = config;
> > phy->mode = phy_mode;
> >
> > if (!phy->config) {
> > if (phy_is_ulpi(phy)) {
> > pr_err("%s: ulpi phy configuration missing",
> > __func__);
> > err = -EINVAL;
> > goto err0;
>
> So, this change will completely break ULPI support, which currently
> works fine. So, NAK.
My initial plan was to add support for phy interfaces one by one.
As part of that thought of UTMI only support at first and then add
ULPI and HSIC in next patches.
However as you were mentioning that it is not correct way, will
push ULPI & UTMI support at once in next patches.
>
> I also plan on deleting devices.[ch] in kernel 3.7, and moving the USB
> platform data into board-dt-tegra20.c, since that's the only place it's
> used right now. So, this patch would conflict with that rather badly. I
> just posted the patches for that to the linux-tegra mailing list last
> night. Do you have better proposals for that? Perhaps usb_phy.c should
> set phy->config to _default in a similar fashion to how it works
> for UTMI; that would remove some of the coupling between the changes.
>
> BTW, in your response to Felipe, you said...
>
> > Thanks Felipe for your comments.
> > Created a patch to separate out phy related stuff to phy.h with you as a
> reviewer.
> > Plz let me know your comments.
>
> ... where is that patch?
Plz see https://lkml.org/lkml/2012/8/28/58
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v10 6/6] allower the user to disable pv event support
Signed-off-by: Wen Congyang
---
hw/pc_piix.c|6 +-
qemu-config.c |4
qemu-options.hx |3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 37eca23..10531a8 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -149,6 +149,8 @@ static void pc_init1(MemoryRegion *system_memory,
MemoryRegion *pci_memory;
MemoryRegion *rom_memory;
void *fw_cfg = NULL;
+QemuOptsList *list = qemu_find_opts("machine");
+bool enable_pv_event;
pc_cpus_init(cpu_model);
@@ -287,7 +289,9 @@ static void pc_init1(MemoryRegion *system_memory,
pc_pci_device_init(pci_bus);
}
-if (kvm_enabled()) {
+enable_pv_event = qemu_opt_get_bool(QTAILQ_FIRST(>head),
+"enable_pv_event", false);
+if (kvm_enabled() && enable_pv_event) {
kvm_pv_event_init(isa_bus);
}
}
diff --git a/qemu-config.c b/qemu-config.c
index c05ffbc..a58bf71 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -612,6 +612,10 @@ static QemuOptsList qemu_machine_opts = {
.name = "dump-guest-core",
.type = QEMU_OPT_BOOL,
.help = "Include guest memory in a core dump",
+}, {
+.name = "enable_pv_event",
+.type = QEMU_OPT_BOOL,
+.help = "handle pv event"
},
{ /* End of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 3c411c4..c825d66 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -38,7 +38,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
"supported accelerators are kvm, xen, tcg (default: tcg)\n"
"kernel_irqchip=on|off controls accelerated irqchip
support\n"
"kvm_shadow_mem=size of KVM shadow MMU\n"
-"dump-guest-core=on|off include guest memory in a core
dump (default=on)\n",
+"dump-guest-core=on|off include guest memory in a core
dump (default=on)\n"
+"enable_pv_event=on|off controls pv event support\n",
QEMU_ARCH_ALL)
STEXI
@item -machine [type=]@var{name}[,prop=@var{value}[,...]]
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 5/6] introduce a new qom device to deal with panicked event
If the target is x86/x86_64, the guest's kernel will write 0x01 to the
port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
event according to panicked_action's value. The possible actions are:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause the guest
3. emit QEVENT_GUEST_PANICKED and poweroff the guest
4. emit QEVENT_GUEST_PANICKED and reset the guest
I/O ports does not work for some targets(for example: s390). And you
can implement another qom device, and include it's code into pv_event.c
for such target.
Note: if we emit QEVENT_GUEST_PANICKED only, and the management
application does not receive this event(the management may not
run when the event is emitted), the management won't know the
guest is panicked.
Signed-off-by: Wen Congyang
---
hw/kvm/Makefile.objs |2 +-
hw/kvm/pv_event.c| 197 ++
hw/pc_piix.c |5 ++
kvm-stub.c |4 +
kvm.h|2 +
5 files changed, 209 insertions(+), 1 deletions(-)
create mode 100644 hw/kvm/pv_event.c
diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
index 226497a..23e3b30 100644
--- a/hw/kvm/Makefile.objs
+++ b/hw/kvm/Makefile.objs
@@ -1 +1 @@
-obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o
+obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pv_event.o
diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
new file mode 100644
index 000..e14b030
--- /dev/null
+++ b/hw/kvm/pv_event.c
@@ -0,0 +1,197 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ * Wen Congyang
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Possible values for action parameter. */
+#define PANICKED_REPORT 1 /* emit QEVENT_GUEST_PANICKED only */
+#define PANICKED_PAUSE 2 /* emit QEVENT_GUEST_PANICKED and pause VM */
+#define PANICKED_POWEROFF 3 /* emit QEVENT_GUEST_PANICKED and quit VM */
+#define PANICKED_RESET 4 /* emit QEVENT_GUEST_PANICKED and reset VM */
+
+#define PV_EVENT_DRIVER "kvm_pv_event"
+
+struct PVEventAction {
+char *panicked_action;
+int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf) \
+DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+static void panicked_mon_event(const char *action)
+{
+QObject *data;
+
+data = qobject_from_jsonf("{ 'action': %s }", action);
+monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
+qobject_decref(data);
+}
+
+static void panicked_perform_action(uint32_t panicked_action)
+{
+switch (panicked_action) {
+case PANICKED_REPORT:
+panicked_mon_event("report");
+break;
+
+case PANICKED_PAUSE:
+panicked_mon_event("pause");
+vm_stop(RUN_STATE_GUEST_PANICKED);
+break;
+
+case PANICKED_POWEROFF:
+panicked_mon_event("poweroff");
+qemu_system_shutdown_request();
+break;
+
+case PANICKED_RESET:
+panicked_mon_event("reset");
+qemu_system_reset_request();
+break;
+}
+}
+
+static uint64_t supported_event(void)
+{
+return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct PVEventAction *conf)
+{
+if (event == KVM_PV_EVENT_PANICKED) {
+panicked_perform_action(conf->panicked_action_value);
+}
+}
+
+static int pv_event_init(struct PVEventAction *conf)
+{
+if (!conf->panicked_action) {
+conf->panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf->panicked_action, "none") == 0) {
+conf->panicked_action_value = PANICKED_REPORT;
+} else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+conf->panicked_action_value = PANICKED_PAUSE;
+} else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+conf->panicked_action_value = PANICKED_POWEROFF;
+} else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+conf->panicked_action_value = PANICKED_RESET;
+} else {
+return -1;
+}
+
+return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "hw/isa.h"
+
+typedef struct {
+ISADevice dev;
+struct PVEventAction conf;
+MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, target_phys_addr_t addr, unsigned
size)
+{
+return supported_event();
+}
+
+static void pv_io_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+unsigned size)
+{
+PVIOPortState *s = opaque;
+
+handle_event(val, >conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+.read = pv_io_read,
+.write = pv_io_write,
+.impl = {
+.min_access_size = 4,
+
[PATCH v10 4/6] add a new qevent: QEVENT_GUEST_PANICKED
This event will be emited when the guest is panicked.
Signed-off-by: Wen Congyang
---
monitor.c |1 +
monitor.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index b17b1bb..f74dd2d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -455,6 +455,7 @@ static const char *monitor_event_names[] = {
[QEVENT_SUSPEND_DISK] = "SUSPEND_DISK",
[QEVENT_WAKEUP] = "WAKEUP",
[QEVENT_BALLOON_CHANGE] = "BALLOON_CHANGE",
+[QEVENT_GUEST_PANICKED] = "GUEST_PANICKED",
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
diff --git a/monitor.h b/monitor.h
index 47d556b..f48a502 100644
--- a/monitor.h
+++ b/monitor.h
@@ -43,6 +43,7 @@ typedef enum MonitorEvent {
QEVENT_SUSPEND_DISK,
QEVENT_WAKEUP,
QEVENT_BALLOON_CHANGE,
+QEVENT_GUEST_PANICKED,
/* Add to 'monitor_event_names' array in monitor.c when
* defining new events here */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
The guest will be in this state when it is panicked.
Signed-off-by: Wen Congyang
---
qapi-schema.json |6 +-
qmp.c|3 ++-
vl.c |7 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index bd8ad74..edb090a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -149,11 +149,15 @@
# @suspended: guest is suspended (ACPI S3)
#
# @watchdog: the watchdog action is configured to pause and has been triggered
+#
+# @guest-panicked: the panicked action is configured to pause and has been
+# triggered.
##
{ 'enum': 'RunState',
'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
+'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
+'guest-panicked' ] }
##
# @StatusInfo:
diff --git a/qmp.c b/qmp.c
index c5a20f1..f863f56 100644
--- a/qmp.c
+++ b/qmp.c
@@ -148,7 +148,8 @@ void qmp_cont(Error **errp)
error_set(errp, QERR_MIGRATION_EXPECTED);
return;
} else if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
- runstate_check(RUN_STATE_SHUTDOWN)) {
+ runstate_check(RUN_STATE_SHUTDOWN) ||
+ runstate_check(RUN_STATE_GUEST_PANICKED)) {
error_set(errp, QERR_RESET_REQUIRED);
return;
} else if (runstate_check(RUN_STATE_SUSPENDED)) {
diff --git a/vl.c b/vl.c
index 316a977..947b23a 100644
--- a/vl.c
+++ b/vl.c
@@ -373,6 +373,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
{ RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
{ RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
+{ RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },
{ RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
@@ -387,6 +388,9 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
{ RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },
+
{ RUN_STATE_MAX, RUN_STATE_MAX },
};
@@ -1607,7 +1611,8 @@ static bool main_loop_should_exit(void)
qemu_system_reset(VMRESET_REPORT);
resume_all_vcpus();
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-runstate_check(RUN_STATE_SHUTDOWN)) {
+runstate_check(RUN_STATE_SHUTDOWN) ||
+runstate_check(RUN_STATE_GUEST_PANICKED)) {
bdrv_iterate(iostatus_bdrv_it, NULL);
vm_start();
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/6] kvm: Update kernel headers
Corresponding kvm.git hash: 1d92128f with my patch for kvm
---
linux-headers/asm-s390/kvm.h |2 +-
linux-headers/asm-s390/kvm_para.h |2 +-
linux-headers/asm-x86/kvm.h |1 +
linux-headers/asm-x86/kvm_para.h |9 +
linux-headers/linux/kvm.h |3 +++
linux-headers/linux/kvm_para.h|6 ++
6 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index bdcbe0f..d25da59 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -1,7 +1,7 @@
#ifndef __LINUX_KVM_S390_H
#define __LINUX_KVM_S390_H
/*
- * asm-s390/kvm.h - KVM s390 specific structures and definitions
+ * KVM s390 specific structures and definitions
*
* Copyright IBM Corp. 2008
*
diff --git a/linux-headers/asm-s390/kvm_para.h
b/linux-headers/asm-s390/kvm_para.h
index 8e2dd67..870051f 100644
--- a/linux-headers/asm-s390/kvm_para.h
+++ b/linux-headers/asm-s390/kvm_para.h
@@ -1,5 +1,5 @@
/*
- * asm-s390/kvm_para.h - definition for paravirtual devices on s390
+ * definition for paravirtual devices on s390
*
* Copyright IBM Corp. 2008
*
diff --git a/linux-headers/asm-x86/kvm.h b/linux-headers/asm-x86/kvm.h
index e7d1c19..246617e 100644
--- a/linux-headers/asm-x86/kvm.h
+++ b/linux-headers/asm-x86/kvm.h
@@ -12,6 +12,7 @@
/* Select x86 specific features in */
#define __KVM_HAVE_PIT
#define __KVM_HAVE_IOAPIC
+#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_DEVICE_ASSIGNMENT
#define __KVM_HAVE_MSI
#define __KVM_HAVE_USER_NMI
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index f2ac46a..53aca59 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -22,6 +22,7 @@
#define KVM_FEATURE_CLOCKSOURCE23
#define KVM_FEATURE_ASYNC_PF 4
#define KVM_FEATURE_STEAL_TIME 5
+#define KVM_FEATURE_PV_EOI 6
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -37,6 +38,7 @@
#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
#define MSR_KVM_STEAL_TIME 0x4b564d03
+#define MSR_KVM_PV_EOI_EN 0x4b564d04
struct kvm_steal_time {
__u64 steal;
@@ -89,5 +91,12 @@ struct kvm_vcpu_pv_apf_data {
__u32 enabled;
};
+#define KVM_PV_EOI_BIT 0
+#define KVM_PV_EOI_MASK (0x1 << KVM_PV_EOI_BIT)
+#define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
+#define KVM_PV_EOI_DISABLED 0x0
+
+#define KVM_PV_EVENT_PORT (0x505UL)
+
#endif /* _ASM_X86_KVM_PARA_H */
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 5a9d4e3..4b9e575 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -617,6 +617,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_SIGNAL_MSI 77
#define KVM_CAP_PPC_GET_SMMU_INFO 78
#define KVM_CAP_S390_COW 79
+#define KVM_CAP_PPC_ALLOC_HTAB 80
#ifdef KVM_CAP_IRQ_ROUTING
@@ -828,6 +829,8 @@ struct kvm_s390_ucas_mapping {
#define KVM_SIGNAL_MSI_IOW(KVMIO, 0xa5, struct kvm_msi)
/* Available with KVM_CAP_PPC_GET_SMMU_INFO */
#define KVM_PPC_GET_SMMU_INFO_IOR(KVMIO, 0xa6, struct kvm_ppc_smmu_info)
+/* Available with KVM_CAP_PPC_ALLOC_HTAB */
+#define KVM_PPC_ALLOCATE_HTAB_IOWR(KVMIO, 0xa7, __u32)
/*
* ioctls for vcpu fds
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index 7bdcf93..f6be0bb 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -20,6 +20,12 @@
#define KVM_HC_FEATURES3
#define KVM_HC_PPC_MAP_MAGIC_PAGE 4
+/* The bit of supported pv event */
+#define KVM_PV_FEATURE_PANICKED0
+
+/* The pv event value */
+#define KVM_PV_EVENT_PANICKED 1
+
/*
* hypercalls use architecture specific
*/
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Parallelize mtrr init between cpus
On 2012-08-08 11:53, H. Peter Anvin wrote: On 08/07/2012 07:08 PM, zhenzhong.duan wrote: 2012-08-08 00:32, H. Peter Anvin wrote: On 08/07/2012 12:29 AM, zhenzhong.duan wrote: Current code serialize mtrr init with set_atomicity_lock. Mtrr init is quite slow when we bootup on a hvm with large mem, vcpus and pci passthroughed devices(eg. 24 vcpus + 90G mem). It took about ~30 mins to bootup, after patch, it took ~2 min. When you're saying "HVM" do you mean "Xen HVM"? How does it behave on native hardware? -hpa Yes, I mean Xen HVM. Bootup at same speed as before on baremetal. Then I would like to know why Xen HVM takes so infernally long. It isn't a good idea to make gratuitous changes in the main kernel to work around defects in Xen. -hpa Hi, Sorrry for late response, I have an opportunity to test the patch on an old G5 with 128 physical CPUS and 1 TB of memory. Arround 0.82 second time saved. Depends on cpu count on the system. I'm curious what's the usage of set_atomicity_lock here? There may be something I missed. thanks Before patch: [ 13.176038] NMI watchdog enabled, takes one hw-pmu counter. [ 13.176444] Brought up 128 CPUs [ 13.176688] Total of 128 processors activated (578760.49 BogoMIPS). [ 14.035223] devtmpfs: initialized [ 17.277652] PM: Registering ACPI NVS region at 7f76e000 (401408 bytes) [ 17.279541] print_constraints: dummy: [ 17.280576] NET: Registered protocol family 16 After patch: [ 13.094227] smpboot cpu 127: start_ip = 9 [ 13.185142] NMI watchdog enabled, takes one hw-pmu counter. [ 13.185599] Brought up 128 CPUs [ 13.185851] Total of 128 processors activated (578871.80 BogoMIPS). [ 13.224783] devtmpfs: initialized [ 16.468002] PM: Registering ACPI NVS region at 7f76e000 (401408 bytes) [ 16.469706] print_constraints: dummy: [ 16.470745] NET: Registered protocol family 16 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 1/6] start vm after reseting it
The guest should run after reseting it, but it does not run if its
old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
We don't set runstate to RUN_STATE_PAUSED when reseting the guest,
so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or
RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).
Signed-off-by: Wen Congyang
---
block.h |2 ++
qmp.c |2 +-
vl.c|7 ---
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block.h b/block.h
index 2e2be11..c3265c2 100644
--- a/block.h
+++ b/block.h
@@ -339,6 +339,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
void bdrv_set_in_use(BlockDriverState *bs, int in_use);
int bdrv_in_use(BlockDriverState *bs);
+void iostatus_bdrv_it(void *opaque, BlockDriverState *bs);
+
enum BlockAcctType {
BDRV_ACCT_READ,
BDRV_ACCT_WRITE,
diff --git a/qmp.c b/qmp.c
index 8463922..c5a20f1 100644
--- a/qmp.c
+++ b/qmp.c
@@ -125,7 +125,7 @@ SpiceInfo *qmp_query_spice(Error **errp)
};
#endif
-static void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
+void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
{
bdrv_iostatus_reset(bs);
}
diff --git a/vl.c b/vl.c
index 7c577fa..316a977 100644
--- a/vl.c
+++ b/vl.c
@@ -343,7 +343,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
{ RUN_STATE_INMIGRATE, RUN_STATE_PRELAUNCH },
-{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
+{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_IO_ERROR, RUN_STATE_RUNNING },
@@ -376,7 +376,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
-{ RUN_STATE_SHUTDOWN, RUN_STATE_PAUSED },
+{ RUN_STATE_SHUTDOWN, RUN_STATE_RUNNING },
{ RUN_STATE_SHUTDOWN, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_DEBUG, RUN_STATE_SUSPENDED },
@@ -1608,7 +1608,8 @@ static bool main_loop_should_exit(void)
resume_all_vcpus();
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
runstate_check(RUN_STATE_SHUTDOWN)) {
-runstate_set(RUN_STATE_PAUSED);
+bdrv_iterate(iostatus_bdrv_it, NULL);
+vm_start();
}
}
if (qemu_wakeup_requested()) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10] kvm: notify host when the guest is panicked
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
Signed-off-by: Wen Congyang
---
Documentation/virtual/kvm/pv_event.txt | 32
arch/ia64/include/asm/kvm_para.h | 14 ++
arch/powerpc/include/asm/kvm_para.h| 14 ++
arch/s390/include/asm/kvm_para.h | 14 ++
arch/x86/include/asm/kvm_para.h| 27 +++
arch/x86/kernel/kvm.c | 25 +
include/linux/kvm_para.h | 23 +++
7 files changed, 149 insertions(+), 0 deletions(-)
create mode 100644 Documentation/virtual/kvm/pv_event.txt
diff --git a/Documentation/virtual/kvm/pv_event.txt
b/Documentation/virtual/kvm/pv_event.txt
new file mode 100644
index 000..bb04de0
--- /dev/null
+++ b/Documentation/virtual/kvm/pv_event.txt
@@ -0,0 +1,32 @@
+The KVM paravirtual event interface
+=
+
+Initializing the paravirtual event interface
+==
+kvm_pv_event_init()
+Argiments:
+ None
+
+Return Value:
+ 0: The guest kernel can use paravirtual event interface.
+ 1: The guest kernel can't use paravirtual event interface.
+
+Querying whether the event can be ejected
+==
+kvm_pv_has_feature()
+Arguments:
+ feature: The bit value of this paravirtual event to query
+
+Return Value:
+ 0 : The guest kernel can't eject this paravirtual event.
+ -1: The guest kernel can eject this paravirtual event.
+
+
+Ejecting paravirtual event
+==
+kvm_pv_eject_event()
+Arguments:
+ event: The event to be ejected.
+
+Return Value:
+ None
diff --git a/arch/ia64/include/asm/kvm_para.h b/arch/ia64/include/asm/kvm_para.h
index 2019cb9..b5ec658 100644
--- a/arch/ia64/include/asm/kvm_para.h
+++ b/arch/ia64/include/asm/kvm_para.h
@@ -31,6 +31,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif
#endif
diff --git a/arch/powerpc/include/asm/kvm_para.h
b/arch/powerpc/include/asm/kvm_para.h
index c18916b..01b98c7 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -211,6 +211,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif /* __KERNEL__ */
#endif /* __POWERPC_KVM_PARA_H__ */
diff --git a/arch/s390/include/asm/kvm_para.h b/arch/s390/include/asm/kvm_para.h
index da44867..00ce058 100644
--- a/arch/s390/include/asm/kvm_para.h
+++ b/arch/s390/include/asm/kvm_para.h
@@ -154,6 +154,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
return false;
}
+static inline int kvm_arch_pv_event_init(void)
+{
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
#endif
#endif /* __S390_KVM_PARA_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 2f7712e..7d297f0 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -96,8 +96,11 @@ struct kvm_vcpu_pv_apf_data {
#define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
#define KVM_PV_EOI_DISABLED 0x0
+#define KVM_PV_EVENT_PORT (0x505UL)
+
#ifdef __KERNEL__
#include
+#include
extern void kvmclock_init(void);
extern int kvm_register_clock(char *txt);
@@ -228,6 +231,30 @@ static inline void kvm_disable_steal_time(void)
}
#endif
+static inline int kvm_arch_pv_event_init(void)
+{
+ if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
+ return -1;
+
+ return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ unsigned int features = inl(KVM_PV_EVENT_PORT);
+
+ /* Reading from an invalid I/O port will return -1 */
+ if (features == ~0)
+ features = 0;
+
+ return features;
+}
+
Re: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote: > On Tue, Aug 28, 2012 at 05:13:05PM +0200, Janusz Krzysztofik wrote: > > On Mon, 27 Aug 2012 14:38:35 Mark Brown wrote: > > > On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote: > > > > > - platform_set_drvdata(ams_delta_audio_platform_device, > > > > - _delta_audio_card); > > > > The real fix here is that you should be using platform data here, not > > > driver data. Is there some reason not to do that? > > > Do you think the change you propose is suitable for the rc cycle? I'm > > trying to fix a regression in the first place. Converting the ams- delta > > asoc to a platform driver is on my todo list and I'm going to take care > > of this as soon as I have enough spare time. > > The above looks like you already have a platform driver? All I'm > suggesting is changing the above to use platform rather than driver > data. The ams-delta asoc driver doesn't use snd_soc_register_card() so far, but relays solely on soc_probe() doing this for it, which in turn expects to find a snc_soc_card structure in drvdata. How is it supposed to find that structure if I pass it over platform data instead? Am I missing something? Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6] mmc: card: Skip secure option for MoviNAND.
For several MoviNAND, there are some known issue with secure option.
For these specific MoviNAND device, we skip secure option.
You could refer this discussion in XDA developers.
http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
Signed-off-by: Ian Chen
Reviewed-by: Namjae Jeon
Acked-by: Jaehoon Chung
Reviewed-by: Linus Walleij
---
drivers/mmc/card/block.c | 24 +++-
include/linux/mmc/card.h |1 +
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f1c84de..0377885 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1411,7 +1411,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
struct request *req)
/* complete ongoing async transfer before issuing discard */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
- if (req->cmd_flags & REQ_SECURE)
+ if (req->cmd_flags & REQ_SECURE &&
+ !(card->quirks & MMC_QUIRK_SEC_ERASE_TRIM_BROKEN))
ret = mmc_blk_issue_secdiscard_rq(mq, req);
else
ret = mmc_blk_issue_discard_rq(mq, req);
@@ -1716,6 +1717,7 @@ force_ro_fail:
#define CID_MANFID_SANDISK 0x2
#define CID_MANFID_TOSHIBA 0x11
#define CID_MANFID_MICRON 0x13
+#define CID_MANFID_SAMSUNG 0x15
static const struct mmc_fixup blk_fixups[] =
{
@@ -1752,6 +1754,26 @@ static const struct mmc_fixup blk_fixups[] =
MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
MMC_QUIRK_LONG_READ_TIME),
+ /*
+* Some issue about secure erase/secure trim for Samsung MoviNAND
+*/
+ MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+
END_FIXUP
};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 111aca5..4b27f9f 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -239,6 +239,7 @@ struct mmc_card {
#define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for regular
multiblock */
#define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8) /* Avoid sending 512
bytes in */
#define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD
says */
+#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10)/* Skip secure for
erase/trim */
/* byte mode */
unsigned intpoweroff_notify_state; /* eMMC4.5 notify feature */
#define MMC_NO_POWER_NOTIFICATION 0
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]Documentation: Chinese translation of Documentation/filesystems/sysfs.txt
This is a Chinese translated version of Documentation/filesystems/sysfs.txt
Signed-off-by: Fu Wei
---
Documentation/zh_CN/filesystems/sysfs.txt | 372 +
1 file changed, 372 insertions(+)
create mode 100644 Documentation/zh_CN/filesystems/sysfs.txt
diff --git a/Documentation/zh_CN/filesystems/sysfs.txt
b/Documentation/zh_CN/filesystems/sysfs.txt
new file mode 100644
index 000..b4bee3a
--- /dev/null
+++ b/Documentation/zh_CN/filesystems/sysfs.txt
@@ -0,0 +1,372 @@
+Chinese translated version of Documentation/filesystems/sysfs.txt
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Patrick Mochel
+ Mike Murphy
+Chinese maintainer: Fu Wei
+-
+Documentation/filesystems/sysfs.txt 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+英文版维护者： Patrick Mochel
+ Mike Murphy
+中文版维护者： 傅炜 Fu Wei
+中文版翻译者： 傅炜 Fu Wei
+中文版校译者： 傅炜 Fu Wei
+
+
+以下为正文
+-
+sysfs - 用于导出内核对象(kobject)的文件系统
+
+Patrick Mochel
+Mike Murphy
+
+修订:16 August 2011
+原始版本: 10 January 2003
+
+
+sysfs 简介:
+~~
+
+sysfs 是一个最初基于 ramfs 且位于内存的文件系统。它提供导出内核
+数据结构及其属性，以及它们之间的关联到用户空间的方法。
+
+sysfs 始终与 kobject 的底层结构紧密相关。请阅读
+Documentation/kobject.txt 文档以获得更多关于 kobject 接口的
+信息。
+
+
+使用 sysfs
+~~~
+
+只要内核配置中定义了 CONFIG_SYSFS ，sysfs 总是被编译进内核。你可
+通过以下命令挂载它:
+
+mount -t sysfs sysfs /sys
+
+
+创建目录
+
+
+任何 kobject 在系统中注册，就会有一个目录在 sysfs 中被创建。这个
+目录是作为该 kobject 的父对象所在目录的子目录创建的，以准确地传递
+内核的对象层次到用户空间。sysfs 中的顶层目录代表着内核对象层次的
+共同祖先；例如：某些对象属于某个子系统。
+
+Sysfs 在与其目录关联的 sysfs_dirent 对象中内部保存一个指向实现
+目录的 kobject 的指针。以前，这个 kobject 指针被 sysfs 直接用于
+kobject 文件打开和关闭的引用计数。而现在的 sysfs 实现中，kobject
+引用计数只能通过 sysfs_schedule_callback() 函数直接修改。
+
+
+属性
+
+
+kobject 的属性可在文件系统中以普通文件的形式导出。Sysfs 为属性定义
+了面向文件 I/O 操作的方法，以提供对内核属性的读写。
+
+
+属性应为 ASCII 码文本文件。以一个文件只存储一个属性值为宜。但一个
+文件只包含一个属性值可能影响效率，所以一个包含相同数据类型的属性值
+数组也被广泛地接受。
+
+混合类型、表达多行数据以及一些怪异的数据格式会遭到强烈反对。这样做是
+很丢脸的,而且其代码会在未通知作者的情况下被重写。
+
+
+一个简单的属性结构定义如下:
+
+struct attribute {
+char* name;
+struct module *owner;
+umode_t mode;
+};
+
+
+int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
+void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
+
+
+一个单独的属性结构并不包含读写其属性值的方法。子系统最好为增删特定
+对象类型的属性定义自己的属性结构体和封装函数。
+
+例如:驱动程序模型定义的 device_attribute 结构体如下:
+
+struct device_attribute {
+ struct attributeattr;
+ ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+ char *buf);
+ ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count);
+};
+
+int device_create_file(struct device *, const struct device_attribute *);
+void device_remove_file(struct device *, const struct device_attribute *);
+
+为了定义设备属性，同时定义了一下辅助宏:
+
+#define DEVICE_ATTR(_name, _mode, _show, _store) \
+struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
+
+例如:声明
+
+static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
+
+等同于如下代码：
+
+static struct device_attribute dev_attr_foo = {
+ .attr = {
+ .name = "foo",
+ .mode = S_IWUSR | S_IRUGO,
+ .show = show_foo,
+ .store = store_foo,
+ },
+};
+
+
+子系统特有的回调函数
+~~~
+
+当一个子系统定义一个新的属性类型时，必须实现一系列的 sysfs 操作，
+以帮助读写调用实现属性所有者的显示和储存方法。
+
+struct sysfs_ops {
+ssize_t (*show)(struct kobject *, struct attribute *, char *);
+ssize_t (*store)(struct kobject *, struct attribute *, const
char *, size_t);
+};
+
+[子系统应已经定义了一个 struct kobj_type 结构体作为这个类型的
+描述符，并在此保存 sysfs_ops 的指针。更多的信息参见 kobject 的
+文档]
+
+sysfs 会为这个类型调用适当的方法。当一个文件被读写时，这个方法会
+将一般的kobject 和 attribute 结构体指针转换为适当的指针类型后
+调用相关联的函数。
+
+
+示例:
+
+#define to_dev(obj) container_of(obj, struct device, kobj)
+#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
+
+static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
+ char *buf)
+{
+struct device_attribute *dev_attr = to_dev_attr(attr);
+struct device *dev = to_dev(kobj);
+ssize_t ret = -EIO;
+
+if (dev_attr->show)
+ret = dev_attr->show(dev, dev_attr, buf);
+if (ret >= (ssize_t)PAGE_SIZE) {
+print_symbol("dev_attr_show: %s returned bad count\n",
+(unsigned long)dev_attr->show);
+}
+return ret;
+}
+
+
+
+读写属性数据
+
+
Re: [RFC PATCH] x86: use new exception_enter()/exception_exit() API in do_device_not_available() (v2)
x86: use new exception_enter()/exception_exit() API in
do_device_not_available()
RCU can be in extended quiescent state when do_device_not_available() called.
[ 676.400274] RCU used illegally from idle CPU!
[ 676.400274] rcu_scheduler_active = 1, debug_locks = 0
[ 676.400278] RCU used illegally from extended quiescent state!
[ 676.400282] 2 locks held by sed/9468:
[ 676.400285] #0: (>lock){-.-.-.}, at: []
__schedule+0x1c0/0x992
[ 676.400304] #1: (rcu_read_lock){.+.+..}, at: []
cpuacct_charge+0x27/0x1e0
[ 676.400321]
[ 676.400329] Call Trace:
[ 676.400340] [] lockdep_rcu_suspicious+0x109/0x112
[ 676.400347] [] cpuacct_charge+0x9e/0x1e0
[ 676.400353] [] ? cpuacct_charge+0x27/0x1e0
[ 676.400359] [] ? __schedule+0x1c0/0x992
[ 676.400366] [] update_curr+0x159/0x200
[ 676.400375] [] ? init_fpu+0x4e/0x8f
[ 676.400382] [] put_prev_task_fair+0x2a/0xac
[ 676.400388] [] __schedule+0x398/0x992
[ 676.400397] [] ? rcu_irq_exit+0x83/0x99
[ 676.400404] [] ? retint_restore_args+0x13/0x13
[ 676.400411] [] ? lock_is_held+0x2d/0xa5
[ 676.400414] [] ? init_fpu+0x4e/0x8f
[ 676.400417] [] __cond_resched+0x28/0x34
[ 676.400420] [] _cond_resched+0x2e/0x35
[ 676.400425] [] kmem_cache_alloc+0x4c/0x1c5
[ 676.400430] [] ? math_state_restore+0x1f/0xdc
[ 676.400433] [] init_fpu+0x4e/0x8f
[ 676.400437] [] math_state_restore+0x2e/0xdc
[ 676.400440] [] do_device_not_available+0xe/0x10
[ 676.400445] [] device_not_available+0x1b/0x20
Signed-off-by: Sergey Senozhatsky
---
arch/x86/kernel/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ab82cbd..fa226ef 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -654,7 +654,9 @@ do_device_not_available(struct pt_regs *regs, long
error_code)
return;
}
#endif
+ exception_enter(regs);
math_state_restore(); /* interrupts still off */
+ exception_exit(regs);
#ifdef CONFIG_X86_32
conditional_sti(regs);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] DMA: PL330: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
DMA clients pdma0 and pdma1 are internal to the SoC and are used only
by dedicated peripherals. Since they cannot be used for generic
purpose, their capability should be set as DMA_PRIVATE.
CC: Vinod Koul
Signed-off-by: Tushar Behera
---
drivers/dma/pl330.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index e4feba6..600ea5e 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2954,6 +2954,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
if (pi->pcfg.num_peri) {
dma_cap_set(DMA_SLAVE, pd->cap_mask);
dma_cap_set(DMA_CYCLIC, pd->cap_mask);
+ dma_cap_set(DMA_PRIVATE, pd->cap_mask);
}
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
DMA clients pdma0 and pdma1 are internal to the SoC and are used only by dedicated peripherals. Since they cannot be used for generic purpose, their capability should be set as DMA_PRIVATE. CC: Kukjin Kim Signed-off-by: Tushar Behera --- arch/arm/mach-exynos/dma.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c index f60b66d..21d568b 100644 --- a/arch/arm/mach-exynos/dma.c +++ b/arch/arm/mach-exynos/dma.c @@ -303,10 +303,12 @@ static int __init exynos_dma_init(void) dma_cap_set(DMA_SLAVE, exynos_pdma0_pdata.cap_mask); dma_cap_set(DMA_CYCLIC, exynos_pdma0_pdata.cap_mask); + dma_cap_set(DMA_PRIVATE, exynos_pdma0_pdata.cap_mask); amba_device_register(_pdma0_device, _resource); dma_cap_set(DMA_SLAVE, exynos_pdma1_pdata.cap_mask); dma_cap_set(DMA_CYCLIC, exynos_pdma1_pdata.cap_mask); + dma_cap_set(DMA_PRIVATE, exynos_pdma1_pdata.cap_mask); amba_device_register(_pdma1_device, _resource); dma_cap_set(DMA_MEMCPY, exynos_mdma1_pdata.cap_mask); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
DMA clients pdma0 and pdma1 are internal to the SoC and are used only by dedicated peripherals. Since they cannot be used for generic purpose, their capability should be set as DMA_PRIVATE. The patches are rebased on top of v3.6-rc3. Tushar Behera (2): ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE DMA: PL330: Set the capability of pdm0 and pdm1 as DMA_PRIVATE arch/arm/mach-exynos/dma.c |2 ++ drivers/dma/pl330.c|1 + 2 files changed, 3 insertions(+), 0 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] x86: use new exception_enter()/exception_exit() API in do_device_not_available()
On (08/29/12 00:11), Borislav Petkov wrote:
> Date: Wed, 29 Aug 2012 00:11:13 +0200
> From: Borislav Petkov
> To: Sergey Senozhatsky
> Cc: Thomas Gleixner , Ingo Molnar ,
> "H. Peter Anvin" , x...@kernel.org, Steven Rostedt
> , Srikar Dronamraju ,
> Peter Zijlstra , "Paul E. McKenney"
> , linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH] x86: use new exception_enter()/exception_exit()
> API in do_device_not_available()
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Wed, Aug 29, 2012 at 12:00:47AM +0300, Sergey Senozhatsky wrote:
> > x86: use new exception_enter()/exception_exit() API in
> > do_device_not_available()
> >
> > RCU can be in extended quiescent state when do_device_not_available()
> > called.
> >
> > [ 676.400274] RCU used illegally from idle CPU!
> > [ 676.400274] rcu_scheduler_active = 1, debug_locks = 0
> > [ 676.400278] RCU used illegally from extended quiescent state!
> > [ 676.400282] 2 locks held by sed/9468:
> > [ 676.400285] #0: (>lock){-.-.-.}, at: []
> > __schedule+0x1c0/0x992
> > [ 676.400304] #1: (rcu_read_lock){.+.+..}, at: []
> > cpuacct_charge+0x27/0x1e0
> > [ 676.400321]
> > [ 676.400329] Call Trace:
> > [ 676.400340] [] lockdep_rcu_suspicious+0x109/0x112
> > [ 676.400347] [] cpuacct_charge+0x9e/0x1e0
> > [ 676.400353] [] ? cpuacct_charge+0x27/0x1e0
> > [ 676.400359] [] ? __schedule+0x1c0/0x992
> > [ 676.400366] [] update_curr+0x159/0x200
> > [ 676.400375] [] ? init_fpu+0x4e/0x8f
> > [ 676.400382] [] put_prev_task_fair+0x2a/0xac
> > [ 676.400388] [] __schedule+0x398/0x992
> > [ 676.400397] [] ? rcu_irq_exit+0x83/0x99
> > [ 676.400404] [] ? retint_restore_args+0x13/0x13
> > [ 676.400411] [] ? lock_is_held+0x2d/0xa5
> > [ 676.400414] [] ? init_fpu+0x4e/0x8f
> > [ 676.400417] [] __cond_resched+0x28/0x34
> > [ 676.400420] [] _cond_resched+0x2e/0x35
> > [ 676.400425] [] kmem_cache_alloc+0x4c/0x1c5
> > [ 676.400430] [] ? math_state_restore+0x1f/0xdc
> > [ 676.400433] [] init_fpu+0x4e/0x8f
> > [ 676.400437] [] math_state_restore+0x2e/0xdc
> > [ 676.400440] [] do_device_not_available+0xe/0x10
> > [ 676.400445] [] device_not_available+0x1b/0x20
> >
> >
> > Signed-off-by: Sergey Senozhatsky
> >
> > ---
> >
> > arch/x86/kernel/traps.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index ab82cbd..dff3e72 100644
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -654,7 +654,9 @@ do_device_not_available(struct pt_regs *regs, long
> > error_code)
> > return;
> > }
> > #endif
> > + exception_enter(regs);
> > math_state_restore(); /* interrupts still off */
> > + exception_enter(regs);
>
> Shouldn't that be exception_exit actually?
>
OH! NO WAY I did that mistake! That was some last minute in-text-editor
changes and somehow I screwed this up. Will re-send in a second.
Sorry, and thank you.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] driver/char/tpm: declare internal symbols as static
From: Xiaoyan Zhang
This patch declares the internal struct and functions as static to provide
more security.
Signed-off-by: Xiaoyan Zhang
Signed-off-by: Fengguang Wu
---
drivers/char/tpm/tpm.c |4 ++--
drivers/char/tpm/tpm_ppi.c | 37 +++--
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 39526c0..6724615 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -915,7 +915,7 @@ EXPORT_SYMBOL_GPL(tpm_show_pcrs);
#define READ_PUBEK_RESULT_SIZE 314
#define TPM_ORD_READPUBEK cpu_to_be32(124)
-struct tpm_input_header tpm_readpubek_header = {
+static struct tpm_input_header tpm_readpubek_header = {
.tag = TPM_TAG_RQU_COMMAND,
.length = cpu_to_be32(30),
.ordinal = TPM_ORD_READPUBEK
@@ -1395,7 +1395,7 @@ EXPORT_SYMBOL_GPL(tpm_dev_vendor_release);
* Once all references to platform device are down to 0,
* release all allocated structures.
*/
-void tpm_dev_release(struct device *dev)
+static void tpm_dev_release(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index 440fa1c..f27b58c 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -53,8 +53,8 @@ static inline void ppi_assign_params(union acpi_object
params[4],
params[3].package.elements = NULL;
}
-ssize_t tpm_show_ppi_version(struct device *dev, struct device_attribute *attr,
-char *buf)
+static ssize_t tpm_show_ppi_version(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
acpi_handle handle;
acpi_status status;
@@ -82,9 +82,8 @@ ssize_t tpm_show_ppi_version(struct device *dev, struct
device_attribute *attr,
return status;
}
-ssize_t tpm_show_ppi_request(struct device *dev,
-struct device_attribute *attr,
-char *buf)
+static ssize_t tpm_show_ppi_request(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
acpi_handle handle;
acpi_status status;
@@ -132,9 +131,9 @@ cleanup:
return status;
}
-ssize_t tpm_store_ppi_request(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t tpm_store_ppi_request(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
{
char version[PPI_VERSION_LEN + 1];
acpi_handle handle;
@@ -207,9 +206,9 @@ ssize_t tpm_store_ppi_request(struct device *dev,
return status;
}
-ssize_t tpm_show_ppi_transition_action(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t tpm_show_ppi_transition_action(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
char version[PPI_VERSION_LEN + 1];
acpi_handle handle;
@@ -269,9 +268,9 @@ ssize_t tpm_show_ppi_transition_action(struct device *dev,
return status;
}
-ssize_t tpm_show_ppi_response(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t tpm_show_ppi_response(struct device *dev,
+struct device_attribute *attr,
+char *buf)
{
acpi_handle handle;
acpi_status status;
@@ -413,14 +412,16 @@ static ssize_t show_ppi_operations(char *buf, u32 start,
u32 end)
return str - buf;
}
-ssize_t tpm_show_ppi_tcg_operations(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t tpm_show_ppi_tcg_operations(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
return show_ppi_operations(buf, 0, PPI_TPM_REQ_MAX);
}
-ssize_t tpm_show_ppi_vs_operations(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t tpm_show_ppi_vs_operations(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
return show_ppi_operations(buf, PPI_VS_REQ_START, PPI_VS_REQ_END);
}
--
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 v6 04/13] pktcdvd: Switch to bio_kmalloc()
On Tue, 28 Aug 2012, Jiri Kosina wrote: On Wed, 22 Aug 2012, Tejun Heo wrote: (cc'ing Jiri, hi!) Hi there! :) On Wed, Aug 22, 2012 at 10:04:01AM -0700, Kent Overstreet wrote: This is prep work for killing bi_destructor - previously, pktcdvd had its own pkt_bio_alloc which was basically duplication bio_kmalloc(), necessitating its own bi_destructor implementation. v5: Un-reorder some functions, to make the patch easier to review Signed-off-by: Kent Overstreet CC: Peter Osterlund Apart from bio_reset() not resetting bi_end_io and bi_private, this looks fine to me but lack of testing makes me a bit hesitant to ack it. Peter doesn't want to be the maintainer of pktcdvd anymore. Maybe Jiri can be tricked into taking this one too? :) Gah, seems like the floppy saga is going to cause me some more trouble in the future ... :) Well, I definitely have hardware back at home that supports this, so I can take it. Doesn't seem to be heavy traffic code either. Peter, ok with that? Also, how was this usually fed upstream -- through Jens' tree? Yes, I am ok with that. -- Peter Osterlund - peterosterlu...@gmail.com, pete...@comhem.se http://web.comhem.se/petero2home -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tcp: Wrong timeout for SYN segments
On Sat, Aug 25, 2012 at 1:48 AM, Alexander Bergmann wrote: > On Fri, Aug 24, 2012 at 01:42:31PM -0400, David Miller wrote: >> Alex, this patch doesn't apply, it was completely corrupted by your email >> client. >> >> Make a fresh submission, with this fixed. But before you do, email the >> patch to yourself and make sure you can actually apply the patch you >> receive in your inbox. Because that's exactly what I'm going to have >> to do. > > Sorry I messed it up the last time. This time I've double checked as > you suggested. I'll keep that in mind. > > From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001 > From: Alexander Bergmann > Date: Fri, 24 Aug 2012 14:09:49 +0200 > Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments > > Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to > RFC6298 (former RFC2988bis). This reduced the time till the last SYN > retransmission packet gets sent from 93secs to 31secs. > > RFC1122 is stating that the retransmission should be done for at least 3 > minutes, but this seems to be quite high. > > "However, the values of R1 and R2 may be different for SYN > and data segments. In particular, R2 for a SYN segment MUST > be set large enough to provide retransmission of the segment > for at least 3 minutes. The application can close the > connection (i.e., give up on the open attempt) sooner, of > course." > > This patch increases the value of TCP_SYN_RETRIES to the value of 6, > providing a retransmission window of 63secs. > > The comments for SYN and SYNACK retries have also been updated to > describe the current settings. > > Signed-off-by: Alexander Bergmann > --- > include/net/tcp.h | 18 ++ > 1 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 1f000ff..d43d6b3 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int > timeo); > * 15 is ~13-30min depending on RTO. > */ > > -#define TCP_SYN_RETRIES 5 /* number of times to retry active > opening a > -* connection: ~180sec is RFC minimum */ > +#define TCP_SYN_RETRIES 6 /* > +* This is how many retries it does to active > +* opening a connection. > +* RFC1122 says the minimum retry MUST be at > +* least 180secs. Nevertheless this value is > +* corresponding to 63secs of retransmission > +* with the current initial RTO. > +*/ > > -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a > -* connection: ~180sec is RFC minimum */ > +#define TCP_SYNACK_RETRIES 5 /* > +* This is how may retries it does to passive > +* opening a connection. > +* This is corresponding to 31secs of > +* retransmission with the current initial > RTO. IMHO 31secs seem a little short. Why not change it to 6 as well because 63 secs still beats 93secs with 3sec initRTO and 5 retries. Jerry > +*/ > > #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT > * state, about 60 seconds */ > -- > 1.7.8.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] fs/proc: Move kfree outside pde_unload_lock
On Tue, 2012-08-28 at 23:38 +0300, Alexey Dobriyan wrote: > Nothing can stop RCU! > > After running "modprobe;rmmod" in a loop and "cat" in another loop for a while > rmmod got stuck in D-state inside remove_proc_entry() with trace amounts of > CPU time > being consumed. > > It didn't oopsed, though. Thanks ! I'll polish this patch once LKS/LPC is over... What particular module and/or proc file did you use for your tests ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Hardening debugfs (Was Re: [PATCH] debugfs: more tightly restrict default mount mode)
On Tue, Aug 28, 2012 at 05:55:45PM -0500, Rob Landley wrote: > I've always been a bit confused by the debugfs design, which seems a > giant compost heap like /proc where we find a specific styrofoam cup > useful and the temporary thing becomes permanent. (Why is there _one_ > debugfs?) The rules for debugfs are very simple: There are no rules. That's it. It's up to the kernel developer to do what they need to do, for debugging stuff, how ever they best see fit. Yes, it replaces proc for all of the debugging stuff that shouldn't have been there before, how it's structured, is up to the developer adding the code. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 09:31:50PM -0400, Vivek Goyal wrote: > On Tue, Aug 28, 2012 at 04:01:08PM -0700, Kent Overstreet wrote: > > On Tue, Aug 28, 2012 at 03:28:00PM -0700, Kent Overstreet wrote: > > > On Tue, Aug 28, 2012 at 01:49:10PM -0700, Tejun Heo wrote: > > > > Overall, I *think* this is correct but need to think more about it to > > > > be sure. > > > > > > Please do. As much time as I've spent staring at this kind of stuff, > > > I'm pretty sure I've got it correct but it still makes my head hurt to > > > work out all the various possible deadlocks. > > > > Hilarious thought: We're punting bios to a rescuer thread that's > > specific to a certain bio_set, right? What if we happen to punt bios > > from a different bio_set? And then the rescuer goes to resubmit those > > bios, and in the process they happen to have dependencies on the > > original bio_set... > > Are they not fully allocated bios and when you submit these to underlying > device, ideally we should not be sharing memory pool at different layers > of stack otherwise we will deadlock any way as stack depth increases. So > there should not be a dependency on original bio_set? > > Or, am I missing something. May be an example will help. Uh, it's more complicated than that. My brain is too fried right now to walk through it in detail, but the problem (if it is a problem; I can't convince myself one way or the other) is roughly: one virt block device stacked on top of another - they both do arbitrary splitting: So once they've submitted a bio, that bio needs to make forward progress even if the thread goes to allocate another bio and blocks before it returns from its make_request fn. That much my patch solves, with the rescuer thread; if the thread goes to block, it punts those blocked bios off to a rescuer thread - and we create one rescuer per bio set. So going back to the stacked block devices, if you've got say dm on top of md (or something else since md doesn't really do much splitting) - each block device will have its own rescuer and everything should be hunky dory. Except that when thread a goes to punt those blocked bios to its rescuer, it punts _all_ the bios on current->bio_list. Even those generated by/belonging to other bio_sets. So thread 1 in device b punts bios to its rescuer, thread 2 But thread 2 ends up with bios for both device a and b - because they're stacked. Thread 2 starts on bios for device a before it gets to those for device b. But a is stacked on top of b, so in the process it generates more bios for b. So now it's uhm... yeah, I'm gonna sleep on this. I'm pretty sure to be rigorously correct filtering the right bios when we punt them to the rescuer is needed, though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86/mm/init.c: devmem_is_allowed() off by one
Fixing an off-by-one error in devmem_is_allowed(), which allows accesses to
physical addresses 0x10-0x100fff, an extra page past 1MB.
Signed-off-by: T Makphaibulchoke
---
arch/x86/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index e0e6990..ab1f6a9 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -319,7 +319,7 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
*/
int devmem_is_allowed(unsigned long pagenr)
{
- if (pagenr <= 256)
+ if (pagenr < 256)
return 1;
if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] oom: remove deprecated oom_adj
On Fri, 24 Aug 2012, Davidlohr Bueso wrote: > The deprecated /proc//oom_adj is scheduled for removal this month. > > Signed-off-by: Davidlohr Bueso Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] HWPOISON: prevent inode cache removal to keep AS_HWPOISON sticky
On Mon, Aug 27, 2012 at 06:05:06PM -0400, Naoya Horiguchi wrote: > On Mon, Aug 27, 2012 at 08:26:07AM +1000, Dave Chinner wrote: > > On Fri, Aug 24, 2012 at 01:24:16PM -0400, Naoya Horiguchi wrote: > > > Let me explain more to clarify my whole scenario. If a memory error > > > hits on a dirty pagecache, kernel works like below: > > > > > > 1. handles a MCE interrupt (logging MCE events,) > > > 2. calls memory error handler (doing 3 to 6,) > > > 3. sets PageHWPoison flag on the error page, > > > 4. unmaps all mappings to processes' virtual addresses, > > > > So nothing in userspace sees the bad page after this. > > > > > 5. sets AS_HWPOISON on mappings to which the error page belongs > > > 6. invalidates the error page (unlinks it from LRU list and removes > > > it from pagecache,) > > > (memory error handler finished) > > > > Ok, so the moment a memory error is handled, the page has been > > removed from the inode's mapping, and it will never be seen by > > aplications again. It's a transient error > > > > > 7. later accesses to the file returns -EIO, > > > 8. AS_HWPOISON is cleared when the file is removed or completely > > > truncated. > > > > so why do we have to keep an EIO on the inode forever? > > > > If the page is not dirty, then just tossing it from the cache (as > > is already done) and rereading it from disk next time it is accessed > > removes the need for any error to be reported at all. It's > > effectively a transient error at this point, and as such no errors > > should be visible from userspace. > > > > If the page is dirty, then it needs to be treated just like any > > other failed page write - the page is invalidated and the address > > space is marked with AS_EIO, and that is reported to the next > > operation that waits on IO on that file (i.e. fsync) > > > > If you have a second application that reads the files that depends > > on a guarantee of good data, then the first step in that process is > > that application that writes it needs to use fsync to check the data > > was written correctly. That ensures that you only have clean pages > > in the cache before the writer closes the file, and any h/w error > > then devolves to the above transient clean page invalidation case. > > Thank you for detailed explanations. > And yes, I understand it's ideal, but many applications choose not to > do that for performance reason. You choose: data integrity or performance. > So I think it's helpful if we can surely report to such applications. If performance is chosen over data integrity, we are under no obligation to keep the error around indefinitely. Fundamentally, ensuring a write completes successfully is the reponsibility of the application, not the kernel. There are so many different filesytem and storage errors that can be lost right now because data is not fsync()d, adding another one to them really doesn't change anything. IOWs, a memory error is no different to a disk failing or the system crashing when it comes to data integrity. If you care, you use fsync(). > > Hence I fail to see why this type of IO error needs to be sticky. > > The error on the mapping is transient - it is gone as soon as the > > page is removed from the mapping. Hence the error can be dropped as > > soon as it is reported to userspace because the mapping is now error > > free. > > It's error free only for the applications which do fsync check in > each write, but not for the applications which don't do. > I think the penalty for the latters (ignore dirty data lost and get > wrong results) is too big to consider it as a reasonable trade-off. I'm guessing that you don't deal with data integrity issues very often. What you are suggesting is not a reasonable tradeoff - either applications are coded correctly for data integrity, or they give up any expectation that errors will be detected and reported reliably. Hoping that we might be able to report an error somewhere to someone who didn't care to avoid or collect in the first place does not improve the situation for anyone Cheers, Dave. -- 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/
[patch v3.6] mm, slab: lock the correct nodelist after reenabling irqs
On Tue, 28 Aug 2012, Haggai Eran wrote:
> Hi,
>
> I believe I have encountered a bug in kernel 3.6-rc3. It starts with the
> assertion in mm/slab.c:2629 failing, and then the system hangs. I can
> reproduce this bug by running a large compilation (compiling the kernel
> for instance).
>
> Here's what I see in netconsole:
> > [ cut here ]
> > kernel BUG at mm/slab.c:2629!
> > invalid opcode: [#1] SMP DEBUG_PAGEALLOC
>
> I'm attaching netconsole logs I got with kernel 3.6-rc1, which contain a
> little more details after the crash, but for some reason netconsole
> didn't capture the full stack trace of the assertion. I caught a glimpse
> at the console and I saw RIP was at cache_alloc_refill.
>
It only gets called from cache_alloc_refill().
Looks like a problem in 072bb0aa5e0 ("mm: sl[au]b: add knowledge of
PFMEMALLOC reserve pages"). cache_grow() can reenable irqs which allows
this to be scheduled on a different cpu, possibly with a different node.
So it turns out that we lock the wrong node's list_lock because we don't
check the new node id when irqs are disabled again.
I doubt you can reliably reproduce this, but the following should fix the
issue.
mm, slab: lock the correct nodelist after reenabling irqs
cache_grow() can reenable irqs so the cpu (and node) can change, so ensure
that we take list_lock on the correct nodelist.
Fixes an issue with 072bb0aa5e0 ("mm: sl[au]b: add knowledge of PFMEMALLOC
reserve pages") where list_lock for the wrong node was taken after growing
the cache.
Reported-by: Haggai Eran
Signed-off-by: David Rientjes
---
mm/slab.c |1 +
1 file changed, 1 insertion(+)
diff --git a/mm/slab.c b/mm/slab.c
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3260,6 +3260,7 @@ force_grow:
/* cache_grow can reenable interrupts, then ac could change. */
ac = cpu_cache_get(cachep);
+ node = numa_mem_id();
/* no objects in sight? abort */
if (!x && (ac->avail == 0 || force_refill))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Hardware breakpoints: Invoke __perf_event_disable() if interrupts are already disabled
On 08/16/2012 01:46 PM, Peter Zijlstra wrote: On Wed, 2012-08-15 at 20:42 +0200, Frederic Weisbecker wrote: On Wed, Aug 15, 2012 at 11:07:01PM +0530, Naveen N. Rao wrote: Hi Frederick, Did you get a chance to take a look at this? Regards, Naveen Yeah, I'm ok with the patch. Peter, are you ok with it? Yeah, queued, it. sorry for loosing track etc.. Hi Peter, Can you please let me know if you plan to push this for v3.6 or if this has been queued for the next kernel release? Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/7] mfd: add syscon driver based on regmap
On Wed, Aug 29, 2012 at 06:54:00AM +0800, Stephen Warren wrote:
> On 08/28/2012 02:09 AM, Dong Aisheng wrote:
> > From: Dong Aisheng
> >
> > Add regmap based syscon driver.
> > This is usually used for access misc bits in registers which does not belong
> > to a specific module, for example, IMX IOMUXC GPR and ANATOP.
> > With this driver, client can use generic regmap API to access registers
> > which are registered into syscon.
>
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> > b/Documentation/devicetree/bindings/mfd/syscon.txt
>
> > +* System Controller Registers R/W driver
>
> I think the binding document could use some information about what a
> "syscon" actually is, especially since the compatible value is something
> generic like "syscon" rather than something with a vendor-specific
> prefix.
Yes, we'd better have it.
> How about:
>
> A system controller node represents a register region containing a set
> of miscellaneous registers. The registers are not cohesive enough to
> represent as any specific type of device. The typical use-case is for
> some other node's driver, or platform-specific code, to acquire a
> reference to the syscon node (e.g. by phandle, node path, or search
> using a specific compatible value), interrogate the node (or associated
> OS driver) to determine the location of the registers, and access the
> registers directly.
>
It looks very good to me.
Thanks for the help.
> > +Required properties:
> > +- compatible: Should contain "syscon".
> > +- reg: the register range can be access from syscon
> > +
> > +Examples:
> > +gpr: iomuxc-gpr@020e {
> > + compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > + reg = <0x020e 0x38>;
> > +};
>
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>
> > +config MFD_SYSCON
> > +bool "System Controller Register R/W Based on Regmap"
> > +select REGMAP_MMIO
> > +help
> > + Select this option to enable accessing system control registers
> > + via regmap.
>
> I think the indentation is off there.
>
You're right.
Will fix it.
> > +static int __devinit syscon_probe(struct platform_device *pdev)
> ...
> > + regcache_cache_only(syscon->regmap, false);
>
> Isn't that the default?
>
Correct, will remove.
> Aside from that, I don't have any particular comments on this series, so
> please consider it,
>
> Acked-by: Stephen Warren
>
Thanks a lot.
Regards
Dong Aisheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] workqueue: single pass rebind_workers
On 08/28/2012 03:04 AM, Tejun Heo wrote: > Hello, Lai. > > On Tue, Aug 28, 2012 at 01:58:24AM +0800, Lai Jiangshan wrote: >> busy_worker_rebind_fn() can't return until all idle workers are rebound, >> the code of busy_worker_rebind_fn() ensure this. >> >> So we can change the order of the code of rebind_workers(), >> and make it a single pass do the rebind_workers(). >> >> It makes the code much clean and better readability. > > I can't see how this could be correct. Could you elaborate more why it is not correct. > What prevents busy worker from > grabbing manager_mutex before idle one? > busy worker still has WORKER_REBIND when it enter busy_worker_rebind_fn(), so it can sleep(include grab the manager_mutex). When this mutex_lock() returns, it means rebind_workers() are done which means all idle are rebound and can be locally woken up. So busy worker can return from busy_worker_rebind_fn() and handle other possible-sleeping items. If the CPU is offline again, the busy worker has WORKER_UNBOUND, it is also correct when it returns from busy_worker_rebind_fn(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] userns: Add basic quota support v4
On Tue, Aug 28, 2012 at 12:09:56PM -0700, Eric W. Biederman wrote:
>
> Add the data type struct kqid which holds the kernel internal form of
> the owning identifier of a quota. struct kqid is a replacement for
> the implicit union of uid, gid and project stored in an unsigned int
> and the quota type field that is was used in the quota data
> structures. Making the data type explicit allows the kuid_t and
> kgid_t type safety to propogate more thoroughly through the code,
> revealing more places where uid/gid conversions need be made.
>
> Along with the data type struct kqid comes the helper functions
> qid_eq, qid_lt, from_kqid, from_kqid_munged, qid_valid, make_kqid,
I think Jan's comment about from_kqid being named id_from_kgid is
better, though I also think it would read better as kqid_to_id().
ie:
id = kqid_to_id(ns, qid);
> make_kqid_invalid, make_kqid_uid, make_kqid_gid.
and these named something like uid_to_kqid()
> Change struct dquot dq_id to a struct kqid and remove the now
> unecessary dq_type.
>
> Update the signature of dqget, quota_send_warning, dquot_get_dqblk,
> and dquot_set_dqblk to use struct kqid.
>
> Make minimal changes to ext3, ext4, gfs2, ocfs2, and xfs to deal with
> the change in quota structures and signatures. The ocfs2 changes are
> larger than most because of the extensive tracing throughout the ocfs2
> quota code that prints out dq_id.
How did you test that this all works? e.g. run xfstests -g quota on
each of those filesystems and check for no regressions? And if you
wrote any tests, can you convert them to be part of xfstests so that
namespace aware quotas get tested regularly?
>
> v4:
> - Rename struct qown struct kqid and associated changes
> to the naming of the helper functions.
> - Use qid_t to hold the userspace identifier representation
> of quota identifiers in all new code.
> v3:
> - Add missing negation on qown_valid
> v2:
> - Renamed qown_t struct qown
> - Added the quota type to struct qown.
> - Removed enum quota_type (In this patch it was just noise)
> - Added qown_lt, make_qown_invalid, make_qown_uid, make_qown_gid
> - Taught qown to handle xfs project ids (but only in init_user_ns).
> Q_XGETQUOTA calls .get_quotblk with project ids.
Q_XSETQLIM was modified to handle project quotas as well, I assume?
> index fed504f..96944c0 100644
> --- a/fs/xfs/xfs_quotaops.c
> +++ b/fs/xfs/xfs_quotaops.c
> @@ -97,28 +97,29 @@ xfs_fs_set_xstate(
> STATIC int
> xfs_fs_get_dqblk(
> struct super_block *sb,
> - int type,
> - qid_t id,
> + struct kqid qid,
> struct fs_disk_quota*fdq)
> {
> struct xfs_mount*mp = XFS_M(sb);
> + xfs_dqid_t xfs_id;
>
> if (!XFS_IS_QUOTA_RUNNING(mp))
> return -ENOSYS;
> if (!XFS_IS_QUOTA_ON(mp))
> return -ESRCH;
>
> - return -xfs_qm_scall_getquota(mp, id, xfs_quota_type(type), fdq);
> + xfs_id = from_kqid(_user_ns, qid);
> + return -xfs_qm_scall_getquota(mp, xfs_id, xfs_quota_type(qid.type),
> fdq);
> }
Why a temporary variable? Why not just:
return -xfs_qm_scall_getquota(mp, from_kqid(_user_ns, qid),
xfs_quota_type(qid.type), fdq);
Indeed, why not drive the struct kqid down another level into
xfs_qm_scall_getquota() where all they are used for is parameters to
the xfs_qm_dqget() function?
>
> STATIC int
> xfs_fs_set_dqblk(
> struct super_block *sb,
> - int type,
> - qid_t id,
> + struct kqid qid,
> struct fs_disk_quota*fdq)
> {
> struct xfs_mount*mp = XFS_M(sb);
> + xfs_dqid_t xfs_id;
>
> if (sb->s_flags & MS_RDONLY)
> return -EROFS;
> @@ -127,7 +128,8 @@ xfs_fs_set_dqblk(
> if (!XFS_IS_QUOTA_ON(mp))
> return -ESRCH;
>
> - return -xfs_qm_scall_setqlim(mp, id, xfs_quota_type(type), fdq);
> + xfs_id = from_kqid(_user_ns, qid);
> + return -xfs_qm_scall_setqlim(mp, xfs_id, xfs_quota_type(qid.type), fdq);
> }
Same is true here
>
> const struct quotactl_ops xfs_quotactl_operations = {
> diff --git a/fs/xfs/xfs_trans_dquot.c b/fs/xfs/xfs_trans_dquot.c
> index bcb6054..46de393 100644
> --- a/fs/xfs/xfs_trans_dquot.c
> +++ b/fs/xfs/xfs_trans_dquot.c
> @@ -575,12 +575,14 @@ xfs_quota_warn(
> struct xfs_dquot*dqp,
> int type)
> {
> + int qtype;
> + struct kqid qid;
> /* no warnings for project quotas - we just return ENOSPC later */
> if (dqp->dq_flags & XFS_DQ_PROJ)
> return;
> - quota_send_warning((dqp->dq_flags & XFS_DQ_USER) ? USRQUOTA : GRPQUOTA,
> -be32_to_cpu(dqp->q_core.d_id), mp->m_super->s_dev,
> -type);
> + qtype = (dqp->dq_flags & XFS_DQ_USER) ? USRQUOTA :
Re: [PATCH] ACPI: power: Use KERN_DEBUG when no power resources are found
On Fri, Aug 24, 2012 at 03:36:21PM -0700, Joe Perches wrote: > On Thu, 2012-08-23 at 15:26 +0200, Borislav Petkov wrote: > > On Fri, Aug 10, 2012 at 10:05:53AM +0800, Aaron Lu wrote: > > > commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link > > > devices which have _PRx, if a device does not have _PRx, a warning > > > message will be printed. > > > > > > This commit is for ZPODD on Intel's platform, on AMD's platform, there > > > is no _PRx to support ZPODD, we use _PSx. > > > > > > So instead of printing a useless warning message on AMD's platform, > > > changing the print level to DEBUG to suppress this message. > [] > > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > [] > > > @@ -460,7 +460,7 @@ int acpi_power_resource_register_device(struct device > > > *dev, acpi_handle handle) > > > return ret; > > > > > > no_power_resource: > > > - printk(KERN_WARNING PREFIX "Invalid Power Resource to register!"); > > > + printk(KERN_DEBUG PREFIX "Invalid Power Resource to register!"); > > Perhaps add something like: > if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) > printk(etc...) > instead? Sorry for not describing this problem clear, this would also occur on Intel platforms as long as that device we are calling this register function on does not have any power resource attached to it. So the problem is actually, does the acpi_power_resource_register_device function expect such input devices that they do not have any power resource attached? If yes, then it shouldn't complain with a warning message; if no, then we should probably check these conditions before making such a call. Looking at the function itself, I think it expects such devices so a warning message here is not appropriate. -Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: otg: Move phy interface to separate file.
>
> #include
> +#include
>
one small thing: is only needed at phy.h.
> /* OTG defines lots of enumeration states before device reset */
> enum usb_otg_state {
> @@ -35,31 +36,6 @@ enum usb_otg_state {
> OTG_STATE_A_VBUS_ERR,
> };
>
> -enum usb_phy_events {
> - USB_EVENT_NONE, /* no events or cable disconnected */
> - USB_EVENT_VBUS, /* vbus valid event */
> - USB_EVENT_ID, /* id was grounded */
> - USB_EVENT_CHARGER, /* usb dedicated charger */
> - USB_EVENT_ENUMERATED, /* gadget driver enumerated */
> -};
> -
> -/* associate a type with PHY */
> -enum usb_phy_type {
> - USB_PHY_TYPE_UNDEFINED,
> - USB_PHY_TYPE_USB2,
> - USB_PHY_TYPE_USB3,
> -};
> -
> -struct usb_phy;
> -
> -/* for transceivers connected thru an ULPI interface, the user must
> - * provide access ops
> - */
> -struct usb_phy_io_ops {
> - int (*read)(struct usb_phy *x, u32 reg);
> - int (*write)(struct usb_phy *x, u32 val, u32 reg);
> -};
> -
> struct usb_otg {
> u8 default_a;
>
> @@ -85,134 +61,9 @@ struct usb_otg {
>
> };
>
> -/*
> - * the otg driver needs to interact with both device side and host side
> - * usb controllers. it decides which controller is active at a given
> - * moment, using the transceiver, ID signal, HNP and sometimes static
> - * configuration information (including "board isn't wired for otg").
> - */
> -struct usb_phy {
> - struct device *dev;
> - const char *label;
> - unsigned int flags;
> -
> - enum usb_phy_type type;
> - enum usb_otg_state state;
> - enum usb_phy_events last_event;
> -
> - struct usb_otg *otg;
> -
> - struct device *io_dev;
> - struct usb_phy_io_ops *io_ops;
> - void __iomem*io_priv;
> -
> - /* for notification of usb_phy_events */
> - struct atomic_notifier_head notifier;
> -
> - /* to pass extra port status to the root hub */
> - u16 port_status;
> - u16 port_change;
> -
> - /* to support controllers that have multiple transceivers */
> - struct list_headhead;
> -
> - /* initialize/shutdown the OTG controller */
> - int (*init)(struct usb_phy *x);
> - void(*shutdown)(struct usb_phy *x);
> -
> - /* effective for B devices, ignored for A-peripheral */
> - int (*set_power)(struct usb_phy *x,
> - unsigned mA);
> -
> - /* for non-OTG B devices: set transceiver into suspend mode */
> - int (*set_suspend)(struct usb_phy *x,
> - int suspend);
> -
> - /* notify phy connect status change */
> - int (*notify_connect)(struct usb_phy *x, int port);
> - int (*notify_disconnect)(struct usb_phy *x, int port);
> -};
> -
> -
> -/* for board-specific init logic */
> -extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
> -extern void usb_remove_phy(struct usb_phy *);
> -
> -#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)
> && defined(MODULE))
> -/* sometimes transceivers are accessed only through e.g. ULPI */
> -extern void usb_nop_xceiv_register(void);
> -extern void usb_nop_xceiv_unregister(void);
> -#else
> -static inline void usb_nop_xceiv_register(void)
> -{
> -}
> -
> -static inline void usb_nop_xceiv_unregister(void)
> -{
> -}
> -#endif
> -
> -/* helpers for direct access thru low-level io interface */
> -static inline int usb_phy_io_read(struct usb_phy *x, u32 reg)
> -{
> - if (x->io_ops && x->io_ops->read)
> - return x->io_ops->read(x, reg);
> -
> - return -EINVAL;
> -}
> -
> -static inline int usb_phy_io_write(struct usb_phy *x, u32 val, u32 reg)
> -{
> - if (x->io_ops && x->io_ops->write)
> - return x->io_ops->write(x, val, reg);
> -
> - return -EINVAL;
> -}
> -
> -static inline int
> -usb_phy_init(struct usb_phy *x)
> -{
> - if (x->init)
> - return x->init(x);
> -
> - return 0;
> -}
> -
> -static inline void
> -usb_phy_shutdown(struct usb_phy *x)
> -{
> - if (x->shutdown)
> - x->shutdown(x);
> -}
> -
> -/* for usb host and peripheral controller drivers */
> #ifdef CONFIG_USB_OTG_UTILS
> -extern struct usb_phy *usb_get_phy(enum usb_phy_type type);
> -extern struct usb_phy *devm_usb_get_phy(struct device *dev,
> - enum usb_phy_type type);
> -extern void usb_put_phy(struct usb_phy *);
> -extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
> extern const char *otg_state_string(enum usb_otg_state state);
> #else
> -static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
> -{
> - return NULL;
> -}
> -
> -static inline struct usb_phy *devm_usb_get_phy(struct device *dev,
> - enum usb_phy_type type)
> -{
> -
RE: [PATCH] lp8727_charger: use IRQF_ONESHOT
> ERROR: Threaded IRQ with no primary handler requested without > IRQF_ONESHOT > > Make sure threaded IRQs without a primary handler are always request > with IRQF_ONESHOT > > Signed-off-by: Fengguang Wu > --- > > Note: I don't really know much about the situation, feel free to > ignore it if it's an false warning. > > cocci-output-25411-2ae2e0-lp8727_charger.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/drivers/power/lp8727_charger.c > +++ b/drivers/power/lp8727_charger.c > @@ -255,7 +255,7 @@ static int lp8727_intr_config(struct lp8 > return request_threaded_irq(pchg->client->irq, > NULL, > lp8727_isr_func, > - IRQF_TRIGGER_FALLING, > + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, > "lp8727_irq", > pchg); > } Thanks for the update. Acked-by: Milo(Woogyom) Kim Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3 V2] workqueue: reimplement rebind_workers()
On 08/29/2012 04:17 AM, Tejun Heo wrote:
> Hello, Lai.
>
> On Tue, Aug 28, 2012 at 07:34:37PM +0800, Lai Jiangshan wrote:
>> So this implement adds an "all_done", thus rebind_workers() can't leave until
>> idle_worker_rebind() successful wait something until all other idle also
>> done,
>> so this "wait something" will not cause deadlock as the old code.
>>
>> The code of "idle_worker_rebind() wait something until all other idle also
>> done"
>> is also changed. It is changed to wait on "worker_rebind.idle_done". With
>> the help of "all_done" this "worker_rebind" is valid when they wait on
>> "worker_rebind.idle_done".
>>
>> The busy_worker_rebind_fn() also explicitly wait on all idle done. It adds
>> a small overhead on cold path, but it makes the rebind_workers() as single
>> pass.
>> Clean Code/Readability wins.
>>
>> "all_cnt" 's decreasing is done without any lock, because this decreasing
>> only happens on the bound CPU, no lock needed. (the bound CPU can't go
>> until we notify on "all_done")
>
> I really hope the fix and reimplementation are done in separate steps.
> All we need is an additional completion wait before leaving
> rebind_workers()(), so let's please just add that to fix the immediate
> bug. If you think it can be further simplified by reimplmenting
> rebind_workers(), that's great but let's please do that as a separate
> step.
>
> Also, I asked this previously but have you encounted this problem or
> is it only from code review?
I didn't notice your ask. I was off-office yesterday and I quickly looked
your replies and quickly code in a netbook.
This "problem" is from code review, I like randomly use "git log"
to show what has changed to the files that I'm interesting in.
I noticed that rebind_worker() is a little "ugly" and tried to make it as
single pass and found this possible problem.
If we have may high-priority task and do offline/online very high
frequently(use high-priority task do it), this problem may happen.
I will try it later.
>
>> static void idle_worker_rebind(struct worker *worker)
>> {
>> -struct global_cwq *gcwq = worker->pool->gcwq;
>> -
>> /* CPU must be online at this point */
>> WARN_ON(!worker_maybe_bind_and_lock(worker));
>> -if (!--worker->idle_rebind->cnt)
>> -complete(>idle_rebind->done);
>> +worker_clr_flags(worker, WORKER_REBIND);
>> +if (!--worker->worker_rebind->idle_cnt)
>> +complete_all(>worker_rebind->idle_done);
>> spin_unlock_irq(>pool->gcwq->lock);
>>
>> -/* we did our part, wait for rebind_workers() to finish up */
>> -wait_event(gcwq->rebind_hold, !(worker->flags & WORKER_REBIND));
>> +/* It did its part, wait for all other idle to finish up */
>> +wait_for_completion(>worker_rebind->idle_done);
>> +
>> +/* all_cnt is only accessed by the bound CPU, don't need any lock */
>> +if (!--worker->worker_rebind->all_cnt)
>
> What if this worker gets preempted by another worker? There's no
> point in this type of optimization in this path. Let's please keep
> things straight-forward and robust.
OK, I was wrong.
>
>> static void busy_worker_rebind_fn(struct work_struct *work)
>> {
>> struct worker *worker = container_of(work, struct worker, rebind_work);
>> struct global_cwq *gcwq = worker->pool->gcwq;
>>
>> -if (worker_maybe_bind_and_lock(worker))
>> -worker_clr_flags(worker, WORKER_REBIND);
>> +/* Wait for all idle to finish up */
>> +wait_for_completion(>worker_rebind->idle_done);
>>
>> +/* CPU must be online at this point */
>> +WARN_ON(!worker_maybe_bind_and_lock(worker));
>> +worker_clr_flags(worker, WORKER_REBIND);
>> spin_unlock_irq(>lock);
>> +
>> +/* all_cnt is only accessed by the bound CPU, don't need any lock */
>> +if (!--worker->worker_rebind->all_cnt)
>> +complete(>worker_rebind->all_done);
>
> You can't do this. There is no guarantee that busy worker will
> execute busy_worker_rebind_fn() in definite amount of time. A given
> work item may run indefinitely.
It can't wait the current running work item to finish and handle
rebind_work item. Do I get your meaning?
OK, I will drop this part.(I want to use a more simple implement to
fix the patch2/3 problem(or say patch 5/7 problem in V1), since the
fix in V1 is OK, It makes no sense to make rebind_workers() wait
busy_worker_rebind_fn())
Thanks
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drivers/gpio/gpio-em.c build error if CONFIG_GPIO_EM=m
Hi Magnus, I got below build error if CONFIG_GPIO_EM=m MODPOST 33 modules ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Regards, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] gpio: mc9s08dz60: Use devm_kzalloc API
Signed-off-by: Axel Lin
---
drivers/gpio/gpio-mc9s08dz60.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-mc9s08dz60.c b/drivers/gpio/gpio-mc9s08dz60.c
index 2738cc4..0ab7000 100644
--- a/drivers/gpio/gpio-mc9s08dz60.c
+++ b/drivers/gpio/gpio-mc9s08dz60.c
@@ -91,10 +91,9 @@ static int mc9s08dz60_direction_output(struct gpio_chip *gc,
static int mc9s08dz60_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- int ret = 0;
struct mc9s08dz60 *mc9s;
- mc9s = kzalloc(sizeof(*mc9s), GFP_KERNEL);
+ mc9s = devm_kzalloc(>dev, sizeof(*mc9s), GFP_KERNEL);
if (!mc9s)
return -ENOMEM;
@@ -110,30 +109,16 @@ static int mc9s08dz60_probe(struct i2c_client *client,
mc9s->client = client;
i2c_set_clientdata(client, mc9s);
- ret = gpiochip_add(>chip);
- if (ret)
- goto error;
-
- return 0;
-
- error:
- kfree(mc9s);
- return ret;
+ return gpiochip_add(>chip);
}
static int mc9s08dz60_remove(struct i2c_client *client)
{
struct mc9s08dz60 *mc9s;
- int ret;
mc9s = i2c_get_clientdata(client);
- ret = gpiochip_remove(>chip);
- if (!ret)
- kfree(mc9s);
-
- return ret;
-
+ return gpiochip_remove(>chip);
}
static const struct i2c_device_id mc9s08dz60_id[] = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] gpio: mc9s08dz60: Fix build error if I2C=m
Make GPIO_MC9S08DZ60 depend on I2C=y, this fixes below build error: LD init/built-in.o drivers/built-in.o: In function `mc9s08dz60_get_value': clk-fixed-factor.c:(.text+0x7214): undefined reference to `i2c_smbus_read_byte_data' drivers/built-in.o: In function `mc9s08dz60_set': clk-fixed-factor.c:(.text+0x727c): undefined reference to `i2c_smbus_read_byte_data' clk-fixed-factor.c:(.text+0x72bc): undefined reference to `i2c_smbus_write_byte_data' drivers/built-in.o: In function `mc9s08dz60_i2c_driver_init': clk-fixed-factor.c:(.init.text+0x290): undefined reference to `i2c_register_driver' drivers/built-in.o: In function `mc9s08dz60_i2c_driver_exit': clk-fixed-factor.c:(.exit.text+0x2c): undefined reference to `i2c_del_driver' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin --- drivers/gpio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index b16c8a7..ba7926f5 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -294,7 +294,7 @@ config GPIO_MAX732X_IRQ config GPIO_MC9S08DZ60 bool "MX35 3DS BOARD MC9S08DZ60 GPIO functions" - depends on I2C && MACH_MX35_3DS + depends on I2C=y && MACH_MX35_3DS help Select this to enable the MC9S08DZ60 GPIO driver -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 04:01:08PM -0700, Kent Overstreet wrote: > On Tue, Aug 28, 2012 at 03:28:00PM -0700, Kent Overstreet wrote: > > On Tue, Aug 28, 2012 at 01:49:10PM -0700, Tejun Heo wrote: > > > Overall, I *think* this is correct but need to think more about it to > > > be sure. > > > > Please do. As much time as I've spent staring at this kind of stuff, > > I'm pretty sure I've got it correct but it still makes my head hurt to > > work out all the various possible deadlocks. > > Hilarious thought: We're punting bios to a rescuer thread that's > specific to a certain bio_set, right? What if we happen to punt bios > from a different bio_set? And then the rescuer goes to resubmit those > bios, and in the process they happen to have dependencies on the > original bio_set... Are they not fully allocated bios and when you submit these to underlying device, ideally we should not be sharing memory pool at different layers of stack otherwise we will deadlock any way as stack depth increases. So there should not be a dependency on original bio_set? Or, am I missing something. May be an example will help. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging/rts_pstor: Use pr_ printks in debug.h
fixed below checkpatch warnings. -WARNING: Prefer pr_debug(... to printk(KERN_DEBUG, ... And added pr_fmt. Signed-off-by: Toshiaki Yamane --- drivers/staging/rts_pstor/debug.h |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rts_pstor/debug.h b/drivers/staging/rts_pstor/debug.h index ab305be..e6b3425 100644 --- a/drivers/staging/rts_pstor/debug.h +++ b/drivers/staging/rts_pstor/debug.h @@ -24,13 +24,13 @@ #ifndef __REALTEK_RTSX_DEBUG_H #define __REALTEK_RTSX_DEBUG_H -#include +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define RTSX_STOR "rts_pstor: " +#include #ifdef CONFIG_RTS_PSTOR_DEBUG -#define RTSX_DEBUGP(x...) printk(KERN_DEBUG RTSX_STOR x) -#define RTSX_DEBUGPN(x...) printk(KERN_DEBUG x) +#define RTSX_DEBUGP(x...) pr_debug(x) +#define RTSX_DEBUGPN(x...) pr_debug(x) #define RTSX_DEBUGPX(x...) printk(x) #define RTSX_DEBUG(x) x #else -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging/rts_pstor: Use pr_ printks in rtsx.c
fixed some checkpatch warnings.
-WARNING: Prefer pr_info(... to printk(KERN_INFO, ...
-WARNING: Prefer pr_err(... to printk(KERN_ERR, ...
-WARNING: quoted string split across lines
And added pr_fmt.
Signed-off-by: Toshiaki Yamane
---
drivers/staging/rts_pstor/rtsx.c | 107 +++---
1 file changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/rts_pstor/rtsx.c b/drivers/staging/rts_pstor/rtsx.c
index 5fb05a2..a44f630 100644
--- a/drivers/staging/rts_pstor/rtsx.c
+++ b/drivers/staging/rts_pstor/rtsx.c
@@ -20,6 +20,8 @@
* No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -170,14 +172,14 @@ static int queuecommand_lck(struct scsi_cmnd *srb,
/* check for state-transition errors */
if (chip->srb != NULL) {
- printk(KERN_ERR "Error in %s: chip->srb = %p\n",
- __func__, chip->srb);
+ pr_err("Error in %s: chip->srb = %p\n",
+ __func__, chip->srb);
return SCSI_MLQUEUE_HOST_BUSY;
}
/* fail the command if we are disconnecting */
if (rtsx_chk_stat(chip, RTSX_STAT_DISCONNECT)) {
- printk(KERN_INFO "Fail command during disconnect\n");
+ pr_info("Fail command during disconnect\n");
srb->result = DID_NO_CONNECT << 16;
done(srb);
return 0;
@@ -204,14 +206,14 @@ static int command_abort(struct scsi_cmnd *srb)
struct rtsx_dev *dev = host_to_rtsx(host);
struct rtsx_chip *chip = dev->chip;
- printk(KERN_INFO "%s called\n", __func__);
+ pr_info("%s called\n", __func__);
scsi_lock(host);
/* Is this command still active? */
if (chip->srb != srb) {
scsi_unlock(host);
- printk(KERN_INFO "-- nothing to abort\n");
+ pr_info("-- nothing to abort\n");
return FAILED;
}
@@ -231,7 +233,7 @@ static int device_reset(struct scsi_cmnd *srb)
{
int result = 0;
- printk(KERN_INFO "%s called\n", __func__);
+ pr_info("%s called\n", __func__);
return result < 0 ? FAILED : SUCCESS;
}
@@ -241,7 +243,7 @@ static int bus_reset(struct scsi_cmnd *srb)
{
int result = 0;
- printk(KERN_INFO "%s called\n", __func__);
+ pr_info("%s called\n", __func__);
return result < 0 ? FAILED : SUCCESS;
}
@@ -303,14 +305,14 @@ static int rtsx_acquire_irq(struct rtsx_dev *dev)
{
struct rtsx_chip *chip = dev->chip;
- printk(KERN_INFO "%s: chip->msi_en = %d, pci->irq = %d\n",
- __func__, chip->msi_en, dev->pci->irq);
+ pr_info("%s: chip->msi_en = %d, pci->irq = %d\n",
+ __func__, chip->msi_en, dev->pci->irq);
if (request_irq(dev->pci->irq, rtsx_interrupt,
chip->msi_en ? 0 : IRQF_SHARED,
CR_DRIVER_NAME, dev)) {
- printk(KERN_ERR "rtsx: unable to grab IRQ %d, "
- "disabling device\n", dev->pci->irq);
+ pr_err("unable to grab IRQ %d, disabling device\n",
+ dev->pci->irq);
return -1;
}
@@ -347,10 +349,10 @@ static int rtsx_suspend(struct pci_dev *pci, pm_message_t
state)
struct rtsx_dev *dev = (struct rtsx_dev *)pci_get_drvdata(pci);
struct rtsx_chip *chip;
- printk(KERN_INFO "Ready to suspend\n");
+ pr_info("Ready to suspend\n");
if (!dev) {
- printk(KERN_ERR "Invalid memory\n");
+ pr_err("Invalid memory\n");
return 0;
}
@@ -386,10 +388,10 @@ static int rtsx_resume(struct pci_dev *pci)
struct rtsx_dev *dev = (struct rtsx_dev *)pci_get_drvdata(pci);
struct rtsx_chip *chip;
- printk(KERN_INFO "Ready to resume\n");
+ pr_info("Ready to resume\n");
if (!dev) {
- printk(KERN_ERR "Invalid memory\n");
+ pr_err("Invalid memory\n");
return 0;
}
@@ -401,8 +403,7 @@ static int rtsx_resume(struct pci_dev *pci)
pci_set_power_state(pci, PCI_D0);
pci_restore_state(pci);
if (pci_enable_device(pci) < 0) {
- printk(KERN_ERR "%s: pci_enable_device failed, "
- "disabling device\n", CR_DRIVER_NAME);
+ pr_err("pci_enable_device failed, disabling device\n");
/* unlock the device pointers */
mutex_unlock(>dev_mutex);
return -EIO;
@@ -435,10 +436,10 @@ static void rtsx_shutdown(struct pci_dev *pci)
struct rtsx_dev *dev = (struct rtsx_dev *)pci_get_drvdata(pci);
struct rtsx_chip *chip;
- printk(KERN_INFO "Ready to shutdown\n");
+ pr_info("Ready to shutdown\n");
if (!dev) {
- printk(KERN_ERR
Re: [PATCH] Add feature-removal-schedule.txt removal to feature-removal-schedule.txt
On Tue, Aug 28, 2012 at 2:22 AM, Steven Rostedt wrote: > The file feature-removal-schedule.txt is ignored by most people except > for people that add to it. It's more of a global TODO list for > developers than being anything useful by anyone. > > Add a feature removal of removing the feature-removal-schedule.txt. > Hi, Steven, I sometimes remind people to remove features scheduled in this file, by sending a proposed patch. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Add rq->nr_uninterruptible count to dest cpu's rq while CPU goes down.
On 8/28/12, Paul E. McKenney wrote: > > OK, but I thought that Peter said that ->nr_uninterruptible was > meaningful only when summed across all CPUs. If that is the case, > it shouldn't matter where the counts are moved. > Yes, right. But, nr_uninterruptible is also use to calculate delta. Please see calc_load_fold_active(). Thanks, Rakib. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()
Dear all, I hope this is the right place to send this sort of backtrace dump. I'm getting the following sort of dumps (below) on a 3.2.27 kernel on an arm/kirkwood (actually DreamPlug) machine that's used as a router. I imagine it being somehow related to the fact that it operates a network bridge (I imagine this because I have another identical machine with exactly the same kernel and a very similar config but not running a bridge, and the warning never pops up). Is this worth investigating? (I will, of course, provide the config file and any other relevant data if the answer is "yes".) Is this potentially serious? (I'm getting hard lockups on this machine which I suspect are due to hardware and unrelated to this, but if someone tells me it could be the cause, I'd be more than happy to believe it.) [24711.204492] [ cut here ] [24711.209151] WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c() [24711.216667] Modules linked in: 8021q ath9k_htc mac80211 ath9k_common ath9k_hw ath cfg80211 bnep rfcomm sit tunnel4 sch_ingress cls_fw cls_u32 sch_sfq sch_htb pppoe pppox ppp_generic slhc bridge stp llc ip6t_REJECT ip6table_filter ip6table_mangle xt_NOTRACK ip6table_raw ip6_tables nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ftp nf_conntrack_ftp ipt_REJECT xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_tcpudp xt_mark iptable_mangle ip_tables x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 orion_wdt ipv6 snd_usb_audio snd_pcm snd_page_alloc snd_hwdep snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi btmrvl_sdio btmrvl snd_seq snd_timer snd_seq_device snd bluetooth soundcore [24711.280663] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x50/0x68) [24711.290124] [] (warn_slowpath_common+0x50/0x68) from [] (warn_slowpath_null+0x1c/0x24) [24711.299845] [] (warn_slowpath_null+0x1c/0x24) from [] (__alloc_pages_nodemask+0x1d4/0x68c) [24711.309914] [] (__alloc_pages_nodemask+0x1d4/0x68c) from [] (__get_free_pages+0x10/0x3c) [24711.319805] [] (__get_free_pages+0x10/0x3c) from [] (kmalloc_order_trace+0x24/0xdc) [24711.329269] [] (kmalloc_order_trace+0x24/0xdc) from [] (pskb_expand_head+0x68/0x298) [24711.338901] [] (pskb_expand_head+0x68/0x298) from [] (ip6_forward+0x4d4/0x7bc [ipv6]) [24711.348638] [] (ip6_forward+0x4d4/0x7bc [ipv6]) from [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) [24711.358333] [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) from [] (__netif_receive_skb+0x544/0x66c) [24711.368106] [] (__netif_receive_skb+0x544/0x66c) from [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) [24711.379899] [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) from [] (br_nf_pre_routing+0x59c/0x67c [bridge]) [24711.392271] [] (br_nf_pre_routing+0x59c/0x67c [bridge]) from [] (nf_iterate+0x8c/0xb4) [24711.401988] [] (nf_iterate+0x8c/0xb4) from [] (nf_hook_slow+0x5c/0x118) [24711.410540] [] (nf_hook_slow+0x5c/0x118) from [] (br_handle_frame+0x1b8/0x290 [bridge]) [24711.420367] [] (br_handle_frame+0x1b8/0x290 [bridge]) from [] (__netif_receive_skb+0x3cc/0x66c) [24711.430872] [] (__netif_receive_skb+0x3cc/0x66c) from [] (mv643xx_eth_poll+0x540/0x734) [24711.440680] [] (mv643xx_eth_poll+0x540/0x734) from [] (net_rx_action+0x118/0x314) [24711.449970] [] (net_rx_action+0x118/0x314) from [] (__do_softirq+0xac/0x234) [24711.458817] [] (__do_softirq+0xac/0x234) from [] (irq_exit+0x94/0x9c) [24711.467046] [] (irq_exit+0x94/0x9c) from [] (handle_IRQ+0x34/0x84) [24711.475007] [] (handle_IRQ+0x34/0x84) from [] (__irq_svc+0x34/0x98) [24711.483068] [] (__irq_svc+0x34/0x98) from [] (kirkwood_enter_idle+0x4c/0x94) [24711.491908] [] (kirkwood_enter_idle+0x4c/0x94) from [] (cpuidle_idle_call+0xc8/0x35c) [24711.501532] [] (cpuidle_idle_call+0xc8/0x35c) from [] (cpu_idle+0x88/0xdc) [24711.510201] [] (cpu_idle+0x88/0xdc) from [] (start_kernel+0x2a0/0x2f0) [24711.518512] ---[ end trace e1776fbe32468909 ]--- -- David A. Madore ( http://www.madore.org/~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: System-drivers ported to Windows XP?
I have a list of drivers here, many of them dated 2001.
http://paradoxuncreated.com/Blog/wordpress/?p=1608 (MS making me upset as
usual.)
I am really just looking for better drivers, and thought maybe someone
knew if more current opensource versions existed. I have not found
anything online though, so therefore I ask here.
I have also thought about the ReactOS project, and wonder if they have
more current drivers, seeing as they work on the project currently, I am
discussing in their forum now, but communication is going slow.
Peace Be With You.
On Wed, 29 Aug 2012 00:50:31 +0200, jdow wrote:
You might look into the ASIO drivers. Although for very heavy audio use
64 byte buffers are a more reliable than the ultra-short buffers you seem
to be using. 100 channels with 7 ms latency through an audio matrix is
a commercial product for XP and Win 7 for quite some time now. (Although
Win 7 has some security policies that reduce performance gains that come
through priority elevation somewhat.)
SoundMan and Richmond are key words that will lead you to it via Google.
{^_^}
On 2012/08/28 12:01, Uwaysi Bin Kareem wrote:
Some may remember me as commenting on the excellent state of the
linux-kernel,
after I achieved 0.3ms reliable latency for audio-streams.
I have now decided to try and get as close as possible on Windows XP
though.
However some of the drivers on my windows XP install, is from 2001.
Windows
update is ofcourse not giving me the available ones from 2012, and they
are hard
to track down.
I was wondering if anyone had ported generic-system drivers, which then
would
probably be more optimized, than the 2001-ones, to windows XP?
If anyone wants to read about my findings on Windows XP, please read:
http://paradoxuncreated.com/Blog/wordpress/?p=1506
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Hardening debugfs (Was Re: [PATCH] debugfs: more tightly restrict default mount mode)
On 08/28/2012 09:41 AM, Theodore Ts'o wrote: > On Mon, Aug 27, 2012 at 01:32:15PM -0700, Kees Cook wrote: >> Since the debugfs is mostly only used by root, make the default mount >> mode 0700. Most system owners do not need a more permissive value, >> but they can choose to weaken the restrictions via their fstab. >> >> Signed-off-by: Kees Cook > > I agree with this patch, but it would also be good if we could try to > harden debugfs in general. Some ideas that might be worth discussing, > for example? > > 1) Adding a per-module flag, so things in debugfs only show up if they > are explicitly requested (you know, for debugging purposes). If most > people are using debugfs for access to ftrace and powertap (my use > case), there's no point making directories for other device drivers > and file systems visible. Are you suggesting "echo 1 > /sys/module/mymod/debug", or are you suggesting "mount -t devfs -o mymod /tmp/mymod", or knobs in devfs? I've always been a bit confused by the debugfs design, which seems a giant compost heap like /proc where we find a specific styrofoam cup useful and the temporary thing becomes permanent. (Why is there _one_ debugfs?) Oh well, presumably too late to change it now. (Unless you mount a tmpfs on /sys/kernel/debug and mkdir mount points in there, but in the perpetual absence of union mounts it would probably involve userspace-visible path changes...) > 2) Can we find a pattern of common security #fail's with debugfs > files, and try to sweep through and fix them? > > There may be other ideas, and again, I'm not saying that this means we > shouldn't lock down the permissions on debugfs. But a both/and > approach might be useful here Plenty of other ideas, but it says "there are no usage rules" right there in the documentation file which makes compatible cleanup hard... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -v12 02/15] resources: Add probe_resource()
On Tue, Aug 28, 2012 at 10:05 AM, Linus Torvalds
wrote:
>
> Ugh. Ok, looking closer at this,
Btw, looking at that code, I also found what looks like a potential
locking bug in allocate_resource().
The code does
if (new->parent)
.. reallocate ..
to check whether a resource was already allocated. HOWEVER, it does so
without actually holding the resource lock. Which means that
"new->parent" might in theory change.
I don't really know if we care. Anybody who does a
"allocate_resource()" on an existing resource that might already be in
the resource tree hopefully does *not* do that in parallel with
another user trying to change the resource allocation, so maybe the
right thing to do is to just say "whatever, if there is a race with
two threads reallocating the same resource at the same time, the bug
is a much more serious one at a higher level".
So this may well be a non-issue. It was introduced some time ago, in
commit 23c570a67448e ("resource: ability to resize an allocated
resource"), since before that we never even allowed re-allocation of
an already allocated resource in the first place, and everything
happened under the lock.
I dunno. Here's a (UNTESTED!) patch that should fix it. Because it's
extremely doubtful whether this is a real problem, I'm certainly not
going to commit it now, much less mark it for stable. But I'm throwing
it out as an RFC. Technically, if people rely on any races being
handled by the resource subsystem, this *could* trigger. But I'm
hoping that the PCI layer has some higher-level locking for
"reallocate the resources of this PCI device". I did *not* check the
callers.
Btw, reallocate_resource() isn't actually used anywhere in the tree
that I can see, so maybe we should remove it and the export, and just
have the __reallocate_resource() that is static to resource.c and is
to be called only with the lock held.
Linus
patch.diff
Description: Binary data
Re: [PATCH 5/5] PCI/xen-pcifront: simplify code by hotplug safe pci_get_domain_bus_and_slot()
On 08/29/2012 12:59 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 28, 2012 at 11:43:58PM +0800, Jiang Liu wrote:
>> Following code has a race window between pci_find_bus() and pci_get_slot()
>> if PCI hotplug operation happens between them which removes the pci_bus.
>> So use PCI hotplug safe interface pci_get_domain_bus_and_slot() instead,
>> which also reduces code complexity.
>
> Has this happend in practice? Is this something one can reproduce
> by manipulating SysFS and at the same time unplugging the PCI
> devices?
Hi Konrad,
We just noticed this issue by code inspection when improving PCI
hotplug implementation. I guess we could trigger such issue by adding
some delay between pci_find_bus() and pci_get_slot().
Regards!
Gerry
>>
>> struct pci_bus *pci_bus = pci_find_bus(domain, busno);
>> struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/pci/xen-pcifront.c | 10 ++
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
>> index d6cc62c..def8d0b 100644
>> --- a/drivers/pci/xen-pcifront.c
>> +++ b/drivers/pci/xen-pcifront.c
>> @@ -982,7 +982,6 @@ static int pcifront_detach_devices(struct
>> pcifront_device *pdev)
>> int err = 0;
>> int i, num_devs;
>> unsigned int domain, bus, slot, func;
>> -struct pci_bus *pci_bus;
>> struct pci_dev *pci_dev;
>> char str[64];
>>
>> @@ -1032,13 +1031,8 @@ static int pcifront_detach_devices(struct
>> pcifront_device *pdev)
>> goto out;
>> }
>>
>> -pci_bus = pci_find_bus(domain, bus);
>> -if (!pci_bus) {
>> -dev_dbg(>xdev->dev, "Cannot get bus %04x:%02x\n",
>> -domain, bus);
>> -continue;
>> -}
>> -pci_dev = pci_get_slot(pci_bus, PCI_DEVFN(slot, func));
>> +pci_dev = pci_get_domain_bus_and_slot(domain, bus,
>> +PCI_DEVFN(slot, func));
>> if (!pci_dev) {
>> dev_dbg(>xdev->dev,
>> "Cannot get PCI device %04x:%02x:%02x.%d\n",
>> --
>> 1.7.9.5
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: max77686: add of_node assignment
On 08/29/2012 02:16 AM, Mark Brown wrote: On Tue, Aug 28, 2012 at 08:25:30PM +0900, Joonyoung Shim wrote: Consumer nodes can reference regulators using -supply from dts file with this patch. Signed-off-by: Joonyoung Shim Signed-off-by: Kyungmin Park This doesn't apply against current code, the changes already appear to be there... OK. I checked it from regulator git for-next branch now. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 04/13] pktcdvd: Switch to bio_kmalloc()
On Wed, 22 Aug 2012, Tejun Heo wrote: > (cc'ing Jiri, hi!) Hi there! :) > On Wed, Aug 22, 2012 at 10:04:01AM -0700, Kent Overstreet wrote: > > This is prep work for killing bi_destructor - previously, pktcdvd had > > its own pkt_bio_alloc which was basically duplication bio_kmalloc(), > > necessitating its own bi_destructor implementation. > > > > v5: Un-reorder some functions, to make the patch easier to review > > > > Signed-off-by: Kent Overstreet > > CC: Peter Osterlund > > Apart from bio_reset() not resetting bi_end_io and bi_private, this > looks fine to me but lack of testing makes me a bit hesitant to ack > it. > > Peter doesn't want to be the maintainer of pktcdvd anymore. Maybe > Jiri can be tricked into taking this one too? :) Gah, seems like the floppy saga is going to cause me some more trouble in the future ... :) Well, I definitely have hardware back at home that supports this, so I can take it. Doesn't seem to be heavy traffic code either. Peter, ok with that? Also, how was this usually fed upstream -- through Jens' tree? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] brcmfmac: Handling the interrupt in ISR directly for non-OOB
On 08/28/2012 04:04 PM, Stephen Warren wrote: On 08/28/2012 04:01 PM, Franky Lin wrote: On 08/28/2012 03:39 PM, Stephen Warren wrote: On 08/28/2012 09:45 AM, Franky Lin wrote: On 08/28/2012 04:13 AM, Wei Ni wrote: On Tue, 2012-08-28 at 04:06 +0800, Stephen Warren wrote: On 08/27/2012 09:24 AM, Arend van Spriel wrote: On 08/27/2012 12:25 PM, Wei Ni wrote: In case of inband interrupts, if we handle the interrupt in dpc thread, two level of thread switching takes place to process wifi interrupts. One in SDHCI driver and the other in Wifi driver. This may cause the system instability. ... Not sure if I can follow this explanation. The isr is called with host claimed (by sdio_irq_thread) and all it does is at a linked list member and signal the dpc thread. After doing this the host is released. Is the issue something like the ISR handler or first level of threading does: * Trigger DPC * Re-enable interrupt So that the interrupt then fires again before the triggered DPC can run to handle/clear it, thus causing an interrupt storm? Whereas handling the interrupt directly prevents this race condition? Above is my understanding. I understand the issue here and totally agree that we should treat in-band and out-band interrupts differently. But my concern is that the behavior of releasing the host before calling brcmf_sdbrcm_isr and grab it after is likely error prone. Also we are restructuring the dpc routine internally and it's almost done. I will find a better solution for in-band interrupt and get it the queue as well. So I suggest dropping this patch. Franky, do you know which kernel release the DPC restructuring will make it into? I ask because I can't apply the rest of the patches in this series without first resolving the stability issues with the Broadcom WiFi enabled, since that'd de-stabilize the Tegra platform significantly, and I'd like to plan when we can apply these patches to Tegra. Thanks! Hi Stephen, Since we submit patches through linux-wireless tree, you may only be able to pick it up at 3.7-rc1. It's quite a big change so I don't think it will qualify as a bug fix to get into 3.6-rcX. That's as quick as I expected it to show up, so that's great. I don't suppose you could mail Wei and myself once the patch gets into the linux-wireless tree, so we can test it out on Tegra. If the patch could possibly go into a topic branch in the wireless tree so it can be merged into the Tegra tree before this series, that would be awesome. Thanks. Will keep you posted. Franky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/13] perf tools: update types definitions for Android
Some systems (e.g. Android) define in their libc types.h
__le16, __be16, etc. Since perf is wrapping
with a local version, we need to define this
constants in the local version too.
Errors in Android:
In file included from bionic/libc/include/netinet/in.h:34:0,
from util/util.h:73,
from util/cache.h:5,
from util/abspath.c:1:
bionic/libc/kernel/common/linux/in6.h:20:2: error: unknown type name '__be16'
bionic/libc/kernel/common/linux/in6.h:21:2: error: unknown type name '__be32'
bionic/libc/kernel/common/linux/in6.h:30:2: error: unknown type name '__be16'
bionic/libc/kernel/common/linux/in6.h:31:2: error: unknown type name '__be32'
bionic/libc/kernel/common/linux/in6.h:47:2: error: unknown type name '__be32'
roundup() definition is also missing:
util/symbol.c: In function 'symbols__fixup_end':
util/symbol.c:106: warning: implicit declaration of function 'roundup'
util/symbol.c:106: warning: nested extern declaration of 'roundup'
Some macro defined in perf are also defined in libc which
leads to redefinition errors. In order to avoid these, we
guard these definitions with #ifndef.
Signed-off-by: Irina Tirdea
---
tools/perf/util/include/linux/compiler.h |4
tools/perf/util/include/linux/kernel.h | 11 +++
tools/perf/util/include/linux/types.h| 15 +++
3 files changed, 30 insertions(+)
diff --git a/tools/perf/util/include/linux/compiler.h
b/tools/perf/util/include/linux/compiler.h
index 2dc8671..ce2367b 100644
--- a/tools/perf/util/include/linux/compiler.h
+++ b/tools/perf/util/include/linux/compiler.h
@@ -12,4 +12,8 @@
#define __used__attribute__((__unused__))
#define __packed__attribute__((__packed__))
+#ifndef __force
+#define __force
+#endif
+
#endif
diff --git a/tools/perf/util/include/linux/kernel.h
b/tools/perf/util/include/linux/kernel.h
index b6842c1..391c425 100644
--- a/tools/perf/util/include/linux/kernel.h
+++ b/tools/perf/util/include/linux/kernel.h
@@ -46,6 +46,17 @@
_min1 < _min2 ? _min1 : _min2; })
#endif
+#ifndef roundup
+#define roundup(x, y) (\
+{ \
+ const typeof(y) __y = y;\
+ (((x) + (__y - 1)) / __y) * __y;\
+} \
+)
+#endif
+
+
+
#ifndef BUG_ON
#define BUG_ON(cond) assert(!(cond))
#endif
diff --git a/tools/perf/util/include/linux/types.h
b/tools/perf/util/include/linux/types.h
index 12de3b8..60a97bb 100644
--- a/tools/perf/util/include/linux/types.h
+++ b/tools/perf/util/include/linux/types.h
@@ -3,6 +3,21 @@
#include
+#ifndef __bitwise__
+#define __bitwise__
+#endif
+
+#ifndef __bitwise
+#define __bitwise
+#endif
+
+typedef __u16 __bitwise __le16;
+typedef __u16 __bitwise __be16;
+typedef __u32 __bitwise __le32;
+typedef __u32 __bitwise __be32;
+typedef __u64 __bitwise __le64;
+typedef __u64 __bitwise __be64;
+
#define DECLARE_BITMAP(name,bits) \
unsigned long name[BITS_TO_LONGS(bits)]
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] brcmfmac: Handling the interrupt in ISR directly for non-OOB
On 08/28/2012 04:01 PM, Franky Lin wrote: > On 08/28/2012 03:39 PM, Stephen Warren wrote: >> On 08/28/2012 09:45 AM, Franky Lin wrote: >>> On 08/28/2012 04:13 AM, Wei Ni wrote: On Tue, 2012-08-28 at 04:06 +0800, Stephen Warren wrote: > On 08/27/2012 09:24 AM, Arend van Spriel wrote: >> On 08/27/2012 12:25 PM, Wei Ni wrote: >>> In case of inband interrupts, if we handle the interrupt in dpc >>> thread, >>> two level of thread switching takes place to process wifi >>> interrupts. >>> One in SDHCI driver and the other in Wifi driver. This may cause the >>> system >>> instability. >> ... >> Not sure if I can follow this explanation. The isr is called with >> host >> claimed (by sdio_irq_thread) and all it does is at a linked list >> member >> and signal the dpc thread. After doing this the host is released. > > Is the issue something like the ISR handler or first level of > threading > does: > > * Trigger DPC > * Re-enable interrupt > > So that the interrupt then fires again before the triggered DPC can > run > to handle/clear it, thus causing an interrupt storm? > > Whereas handling the interrupt directly prevents this race condition? Above is my understanding. >>> >>> I understand the issue here and totally agree that we should treat >>> in-band and out-band interrupts differently. But my concern is that the >>> behavior of releasing the host before calling brcmf_sdbrcm_isr and grab >>> it after is likely error prone. Also we are restructuring the dpc >>> routine internally and it's almost done. I will find a better solution >>> for in-band interrupt and get it the queue as well. So I suggest >>> dropping this patch. >> >> Franky, do you know which kernel release the DPC restructuring will make >> it into? I ask because I can't apply the rest of the patches in this >> series without first resolving the stability issues with the Broadcom >> WiFi enabled, since that'd de-stabilize the Tegra platform >> significantly, and I'd like to plan when we can apply these patches to >> Tegra. Thanks! >> > > Hi Stephen, > > Since we submit patches through linux-wireless tree, you may only be > able to pick it up at 3.7-rc1. It's quite a big change so I don't think > it will qualify as a bug fix to get into 3.6-rcX. That's as quick as I expected it to show up, so that's great. I don't suppose you could mail Wei and myself once the patch gets into the linux-wireless tree, so we can test it out on Tegra. If the patch could possibly go into a topic branch in the wireless tree so it can be merged into the Tegra tree before this series, that would be awesome. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] brcmfmac: Handling the interrupt in ISR directly for non-OOB
On 08/28/2012 03:39 PM, Stephen Warren wrote: On 08/28/2012 09:45 AM, Franky Lin wrote: On 08/28/2012 04:13 AM, Wei Ni wrote: On Tue, 2012-08-28 at 04:06 +0800, Stephen Warren wrote: On 08/27/2012 09:24 AM, Arend van Spriel wrote: On 08/27/2012 12:25 PM, Wei Ni wrote: In case of inband interrupts, if we handle the interrupt in dpc thread, two level of thread switching takes place to process wifi interrupts. One in SDHCI driver and the other in Wifi driver. This may cause the system instability. ... Not sure if I can follow this explanation. The isr is called with host claimed (by sdio_irq_thread) and all it does is at a linked list member and signal the dpc thread. After doing this the host is released. Is the issue something like the ISR handler or first level of threading does: * Trigger DPC * Re-enable interrupt So that the interrupt then fires again before the triggered DPC can run to handle/clear it, thus causing an interrupt storm? Whereas handling the interrupt directly prevents this race condition? Above is my understanding. I understand the issue here and totally agree that we should treat in-band and out-band interrupts differently. But my concern is that the behavior of releasing the host before calling brcmf_sdbrcm_isr and grab it after is likely error prone. Also we are restructuring the dpc routine internally and it's almost done. I will find a better solution for in-band interrupt and get it the queue as well. So I suggest dropping this patch. Franky, do you know which kernel release the DPC restructuring will make it into? I ask because I can't apply the rest of the patches in this series without first resolving the stability issues with the Broadcom WiFi enabled, since that'd de-stabilize the Tegra platform significantly, and I'd like to plan when we can apply these patches to Tegra. Thanks! Hi Stephen, Since we submit patches through linux-wireless tree, you may only be able to pick it up at 3.7-rc1. It's quite a big change so I don't think it will qualify as a bug fix to get into 3.6-rcX. Regards, Franky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 03:28:00PM -0700, Kent Overstreet wrote: > On Tue, Aug 28, 2012 at 01:49:10PM -0700, Tejun Heo wrote: > > Overall, I *think* this is correct but need to think more about it to > > be sure. > > Please do. As much time as I've spent staring at this kind of stuff, > I'm pretty sure I've got it correct but it still makes my head hurt to > work out all the various possible deadlocks. Hilarious thought: We're punting bios to a rescuer thread that's specific to a certain bio_set, right? What if we happen to punt bios from a different bio_set? And then the rescuer goes to resubmit those bios, and in the process they happen to have dependencies on the original bio_set... I think it's actually necessary to filter out only bios from the current bio_set to punt to the rescuer. God I love the block layer sometimes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
> * Sasha Levin (levinsasha...@gmail.com) wrote:
> > On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
> > > * Sasha Levin (levinsasha...@gmail.com) wrote:
> > >> On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
> > >>> * Tejun Heo (t...@kernel.org) wrote:
> > Hello,
> >
> > On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> > > Thats the thing, the amount of things of things you can do with a
> > > given bucket
> > > is very limited. You can't add entries to any point besides the head
> > > (without
> > > walking the entire list).
> >
> > Kinda my point. We already have all the hlist*() interface to deal
> > with such cases. Having something which is evidently the trivial
> > hlist hashtable and advertises as such in the interface can be
> > helpful. I think we need that more than we need anything fancy.
> >
> > Heh, this is a debate about which one is less insignificant. I can
> > see your point. I'd really like to hear what others think on this.
> >
> > Guys, do we want something which is evidently trivial hlist hashtable
> > which can use hlist_*() API directly or do we want something better
> > encapsulated?
> > >>>
> > >>> My 2 cents, FWIW: I think this specific effort should target a trivially
> > >>> understandable API and implementation, for use-cases where one would be
> > >>> tempted to reimplement his own trivial hash table anyway. So here
> > >>> exposing hlist internals, with which kernel developers are already
> > >>> familiar, seems like a good approach in my opinion, because hiding stuff
> > >>> behind new abstraction might make the target users go away.
> > >>>
> > >>> Then, as we see the need, we can eventually merge a more elaborate hash
> > >>> table with poneys and whatnot, but I would expect that the trivial hash
> > >>> table implementation would still be useful. There are of course very
> > >>> compelling reasons to use a more featureful hash table: automatic
> > >>> resize, RT-aware updates, scalable updates, etc... but I see a purpose
> > >>> for a trivial implementation. Its primary strong points being:
> > >>>
> > >>> - it's trivially understandable, so anyone how want to be really sure
> > >>> they won't end up debugging the hash table instead of their
> > >>> work-in-progress code can have a full understanding of it,
> > >>> - it has few dependencies, which makes it easier to understand and
> > >>> easier to use in some contexts (e.g. early boot).
> > >>>
> > >>> So I'm in favor of not overdoing the abstraction for this trivial hash
> > >>> table, and honestly I would rather prefer that this trivial hash table
> > >>> stays trivial. A more elaborate hash table should probably come as a
> > >>> separate API.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Mathieu
> > >>>
> > >>
> > >> Alright, let's keep it simple then.
> > >>
> > >> I do want to keep the hash_for_each[rcu,safe] family though.
> > >
> > > Just a thought: if the API offered by the simple hash table focus on
> > > providing a mechanism to find the hash bucket to which belongs the hash
> > > chain containing the key looked up, and then expects the user to use the
> > > hlist API to iterate on the chain (with or without the hlist _rcu
> > > variant), then it might seem consistent that a helper providing
> > > iteration over the entire table would actually just provide iteration on
> > > all buckets, and let the user call the hlist for each iterator for each
> > > node within the bucket, e.g.:
> > >
> > > struct hlist_head *head;
> > > struct hlist_node *pos;
> > >
> > > hash_for_each_bucket(ht, head) {
> > > hlist_for_each(pos, head) {
> > > ...
> > > }
> > > }
> > >
> > > That way you only have to provide one single macro
> > > (hash_for_each_bucket), and rely on the already existing:
> > >
> > > - hlist_for_each_entry
> > > - hlist_for_each_safe
> > > - hlist_for_each_entry_rcu
> > > - hlist_for_each_safe_rcu
> > > .
> > >
> > > and various flavors that can appear in the future without duplicating
> > > this API. So you won't even have to create _rcu, _safe, nor _safe_rcu
> > > versions of the hash_for_each_bucket macro.
> > >
> > > Thoughts ?
> >
> > In my opinion, the downside here is that it'll require 2 function calls and
> > 2
> > levels of nesting for a simple hash iteration.
>
> Those are macros, not functions. No function call is required. But I see
> your point about nesting.
>
> >
> > hash_for_each_bucket() will always be followed by an iteration of that
> > bucket, so splitting a hash_for_each() which does both into 2
> > different functions which will almost always must be called in that
> > given order sounds unintuitive to me.
> >
> > It's also just 3 different possible iterators:
> >
> > - hlist_for_each_entry
> > - hlist_for_each_entry_safe
> > - hlist_for_each_entry_rcu
>
Re: [PATCH] x86, apm: Make on_cpu0() use workqueue instead of work_on_cpu()
On Thu, 23 Aug 2012, Tejun Heo wrote: > Make APM schedule a work item on CPU0 instead of using the expensive > work_on_cpu(); hopefully, this is the last user of work_on_cpu() and > we can take out work_on_cpu() in not too distant future. > > Tested both paths. Seems to work fine. Applying to apm.git, thanks Tejun. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/9] block: Add bio_reset()
On Tue, Aug 28, 2012 at 03:17:15PM -0700, Kent Overstreet wrote:
> On Tue, Aug 28, 2012 at 01:31:48PM -0700, Tejun Heo wrote:
> > > + unsigned long flags = bio->bi_flags & (~0UL << BIO_RESET_BITS);
> > > +
> > > + if (bio_integrity(bio))
> > > + bio_integrity_free(bio, bio->bi_pool);
> > > +
> > > + bio_disassociate_task(bio);
> >
> > Is this desirable? Why?
>
> *twitch* I should've thought more when I made that change.
>
> It occurs to me now that we specifically talked about that and decided
> to do it the other way - when I changed that I was just looking at
> bio_free() and decided they needed to be symmetrical.
>
> I still think they should be symmetrical, but if that's true bi_ioc and
> bi_css need to be moved, and also bio_disassociate_task() should be
> getting called from bio_free(), not bio_put().
Though - looking at it again I didn't actually screw anything up when I
made that change, it's just bad style.
Just screwing around a bit with the patch below, but - couple thoughts:
1) I hate duplicated code, and for the stuff in
bio_init()/bio_free()/bio_reset() it's perhaps not worth it, it is the
kind of stuff that gets out of sync.
2) It'd be better to have bio_reset() reset as much as possible, i.e. be
as close to bio_init() as posible. Fewer differences to confuse people.
diff --git a/fs/bio-integrity.c b/fs/bio-integrity.c
index 7c8fe1d..a38bc7d 100644
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@ -148,6 +148,9 @@ void bio_integrity_free(struct bio *bio, struct bio_set *bs)
BUG_ON(bip == NULL);
+ if (!bs)
+ bs = fs_bio_set;
+
/* A cloned bio doesn't own the integrity metadata */
if (!bio_flagged(bio, BIO_CLONED) && !bio_flagged(bio, BIO_FS_INTEGRITY)
&& bip->bip_buf != NULL)
diff --git a/fs/bio.c b/fs/bio.c
index c938f42..56d8fa2 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -234,39 +234,47 @@ fallback:
return bvl;
}
+static void bio_free_stuff(struct bio *bio)
+{
+ bio_disassociate_task(bio);
+
+ if (bio_integrity(bio))
+ bio_integrity_free(bio, bio->bi_pool);
+}
+
void bio_free(struct bio *bio)
{
struct bio_set *bs = bio->bi_pool;
void *p;
+ bio_free_stuff(bio);
+
if (!bs) {
- /* Bio was allocated by bio_kmalloc() */
- if (bio_integrity(bio))
- bio_integrity_free(bio, fs_bio_set);
kfree(bio);
- return;
- }
-
- if (bio_has_allocated_vec(bio))
- bvec_free_bs(bs, bio->bi_io_vec, BIO_POOL_IDX(bio));
+ } else {
+ if (bio_has_allocated_vec(bio))
+ bvec_free_bs(bs, bio->bi_io_vec, BIO_POOL_IDX(bio));
- if (bio_integrity(bio))
- bio_integrity_free(bio, bs);
+ /*
+* If we have front padding, adjust the bio pointer before
freeing
+*/
+ p = bio;
+ if (bs->front_pad)
+ p -= bs->front_pad;
- /*
-* If we have front padding, adjust the bio pointer before freeing
-*/
- p = bio;
- if (bs->front_pad)
- p -= bs->front_pad;
+ mempool_free(p, bs->bio_pool);
+ }
+}
- mempool_free(p, bs->bio_pool);
+static void __bio_init(struct bio *bio)
+{
+ memset(bio, 0, BIO_RESET_BYTES);
+ bio->bi_flags = 1 << BIO_UPTODATE;
}
void bio_init(struct bio *bio)
{
- memset(bio, 0, sizeof(*bio));
- bio->bi_flags = 1 << BIO_UPTODATE;
+ __bio_init(bio);
atomic_set(>bi_cnt, 1);
}
EXPORT_SYMBOL(bio_init);
@@ -275,13 +283,10 @@ void bio_reset(struct bio *bio)
{
unsigned long flags = bio->bi_flags & (~0UL << BIO_RESET_BITS);
- if (bio_integrity(bio))
- bio_integrity_free(bio, bio->bi_pool);
+ bio_free_stuff(bio);
+ __bio_init(bio);
- bio_disassociate_task(bio);
-
- memset(bio, 0, BIO_RESET_BYTES);
- bio->bi_flags = flags|(1 << BIO_UPTODATE);
+ bio->bi_flags |= flags;
}
EXPORT_SYMBOL(bio_reset);
@@ -440,10 +445,8 @@ void bio_put(struct bio *bio)
/*
* last put frees it
*/
- if (atomic_dec_and_test(>bi_cnt)) {
- bio_disassociate_task(bio);
+ if (atomic_dec_and_test(>bi_cnt))
bio_free(bio);
- }
}
EXPORT_SYMBOL(bio_put);
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index ca63847..28bddc0 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -68,15 +68,6 @@ struct bio {
struct bvec_iterbi_iter;
- /*
-* Everything starting with bi_max_vecs will be preserved by bio_reset()
-*/
-
- unsigned intbi_max_vecs;/* max bvl_vecs we can hold */
-
- atomic_tbi_cnt; /* pin count */
-
- struct bio_vec *bi_io_vec; /* the actual
Re: [PATCH v3 1/7] mfd: add syscon driver based on regmap
On 08/28/2012 02:09 AM, Dong Aisheng wrote:
> From: Dong Aisheng
>
> Add regmap based syscon driver.
> This is usually used for access misc bits in registers which does not belong
> to a specific module, for example, IMX IOMUXC GPR and ANATOP.
> With this driver, client can use generic regmap API to access registers
> which are registered into syscon.
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> +* System Controller Registers R/W driver
I think the binding document could use some information about what a
"syscon" actually is, especially since the compatible value is something
generic like "syscon" rather than something with a vendor-specific
prefix. How about:
A system controller node represents a register region containing a set
of miscellaneous registers. The registers are not cohesive enough to
represent as any specific type of device. The typical use-case is for
some other node's driver, or platform-specific code, to acquire a
reference to the syscon node (e.g. by phandle, node path, or search
using a specific compatible value), interrogate the node (or associated
OS driver) to determine the location of the registers, and access the
registers directly.
> +Required properties:
> +- compatible: Should contain "syscon".
> +- reg: the register range can be access from syscon
> +
> +Examples:
> +gpr: iomuxc-gpr@020e {
> + compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> + reg = <0x020e 0x38>;
> +};
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> +config MFD_SYSCON
> +bool "System Controller Register R/W Based on Regmap"
> +select REGMAP_MMIO
> +help
> + Select this option to enable accessing system control registers
> + via regmap.
I think the indentation is off there.
> +static int __devinit syscon_probe(struct platform_device *pdev)
...
> + regcache_cache_only(syscon->regmap, false);
Isn't that the default?
Aside from that, I don't have any particular comments on this series, so
please consider it,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] brcmfmac: Handling the interrupt in ISR directly for non-OOB
On 08/28/2012 09:45 AM, Franky Lin wrote: > On 08/28/2012 04:13 AM, Wei Ni wrote: >> On Tue, 2012-08-28 at 04:06 +0800, Stephen Warren wrote: >>> On 08/27/2012 09:24 AM, Arend van Spriel wrote: On 08/27/2012 12:25 PM, Wei Ni wrote: > In case of inband interrupts, if we handle the interrupt in dpc > thread, > two level of thread switching takes place to process wifi interrupts. > One in SDHCI driver and the other in Wifi driver. This may cause the > system > instability. ... Not sure if I can follow this explanation. The isr is called with host claimed (by sdio_irq_thread) and all it does is at a linked list member and signal the dpc thread. After doing this the host is released. >>> >>> Is the issue something like the ISR handler or first level of threading >>> does: >>> >>> * Trigger DPC >>> * Re-enable interrupt >>> >>> So that the interrupt then fires again before the triggered DPC can run >>> to handle/clear it, thus causing an interrupt storm? >>> >>> Whereas handling the interrupt directly prevents this race condition? >> >> Above is my understanding. > > I understand the issue here and totally agree that we should treat > in-band and out-band interrupts differently. But my concern is that the > behavior of releasing the host before calling brcmf_sdbrcm_isr and grab > it after is likely error prone. Also we are restructuring the dpc > routine internally and it's almost done. I will find a better solution > for in-band interrupt and get it the queue as well. So I suggest > dropping this patch. Franky, do you know which kernel release the DPC restructuring will make it into? I ask because I can't apply the rest of the patches in this series without first resolving the stability issues with the Broadcom WiFi enabled, since that'd de-stabilize the Tegra platform significantly, and I'd like to plan when we can apply these patches to Tegra. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/13] perf tools: update types definitions for Android
Some systems (e.g. Android) define in their libc types.h
__le16, __be16, etc. Since perf is wrapping
with a local version, we need to define this
constants in the local version too.
Errors in Android:
In file included from bionic/libc/include/netinet/in.h:34:0,
from util/util.h:73,
from util/cache.h:5,
from util/abspath.c:1:
bionic/libc/kernel/common/linux/in6.h:20:2: error: unknown type name '__be16'
bionic/libc/kernel/common/linux/in6.h:21:2: error: unknown type name '__be32'
bionic/libc/kernel/common/linux/in6.h:30:2: error: unknown type name '__be16'
bionic/libc/kernel/common/linux/in6.h:31:2: error: unknown type name '__be32'
bionic/libc/kernel/common/linux/in6.h:47:2: error: unknown type name '__be32'
roundup() definition is also missing:
util/symbol.c: In function 'symbols__fixup_end':
util/symbol.c:106: warning: implicit declaration of function 'roundup'
util/symbol.c:106: warning: nested extern declaration of 'roundup'
Some macro defined in perf are also defined in libc which
leads to redefinition errors. In order to avoid these, we
guard these definitions with #ifndef.
Signed-off-by: Irina Tirdea
---
tools/perf/util/include/linux/compiler.h |4
tools/perf/util/include/linux/kernel.h | 11 +++
tools/perf/util/include/linux/types.h| 15 +++
3 files changed, 30 insertions(+)
diff --git a/tools/perf/util/include/linux/compiler.h
b/tools/perf/util/include/linux/compiler.h
index 2dc8671..ce2367b 100644
--- a/tools/perf/util/include/linux/compiler.h
+++ b/tools/perf/util/include/linux/compiler.h
@@ -12,4 +12,8 @@
#define __used __attribute__((__unused__))
#define __packed __attribute__((__packed__))
+#ifndef __force
+#define __force
+#endif
+
#endif
diff --git a/tools/perf/util/include/linux/kernel.h
b/tools/perf/util/include/linux/kernel.h
index b6842c1..391c425 100644
--- a/tools/perf/util/include/linux/kernel.h
+++ b/tools/perf/util/include/linux/kernel.h
@@ -46,6 +46,17 @@
_min1 < _min2 ? _min1 : _min2; })
#endif
+#ifndef roundup
+#define roundup(x, y) (\
+{ \
+ const typeof(y) __y = y;\
+ (((x) + (__y - 1)) / __y) * __y;\
+} \
+)
+#endif
+
+
+
#ifndef BUG_ON
#define BUG_ON(cond) assert(!(cond))
#endif
diff --git a/tools/perf/util/include/linux/types.h
b/tools/perf/util/include/linux/types.h
index 12de3b8..60a97bb 100644
--- a/tools/perf/util/include/linux/types.h
+++ b/tools/perf/util/include/linux/types.h
@@ -3,6 +3,21 @@
#include
+#ifndef __bitwise__
+#define __bitwise__
+#endif
+
+#ifndef __bitwise
+#define __bitwise
+#endif
+
+typedef __u16 __bitwise __le16;
+typedef __u16 __bitwise __be16;
+typedef __u32 __bitwise __le32;
+typedef __u32 __bitwise __be32;
+typedef __u64 __bitwise __le64;
+typedef __u64 __bitwise __be64;
+
#define DECLARE_BITMAP(name,bits) \
unsigned long name[BITS_TO_LONGS(bits)]
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 01:49:10PM -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 28, 2012 at 10:37:36AM -0700, Kent Overstreet wrote:
> > @@ -324,13 +342,37 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
> > nr_iovecs, struct bio_set *bs)
> > front_pad = 0;
> > inline_vecs = nr_iovecs;
> > } else {
> > + /*
> > +* generic_make_request() converts recursion to iteration; this
> > +* means if we're running beneath it, any bios we allocate and
> > +* submit will not be submitted (and thus freed) until after we
> > +* return.
> > +*
> > +* This exposes us to a potential deadlock if we allocate
> > +* multiple bios from the same bio_set() while running
> > +* underneath generic_make_request(). If we were to allocate
> > +* multiple bios (say a stacking block driver that was splitting
> > +* bios), we would deadlock if we exhausted the mempool's
> > +* reserve.
> > +*
> > +* We solve this, and guarantee forward progress, with a rescuer
> > +* workqueue per bio_set. If we go to allocate and there are
> > +* bios on current->bio_list, we first try the allocation
> > +* without __GFP_WAIT; if that fails, we punt those bios we
> > +* would be blocking to the rescuer workqueue before we retry
> > +* with the original gfp_flags.
> > +*/
> > +
> > + if (current->bio_list && !bio_list_empty(current->bio_list))
> > + gfp_mask &= ~__GFP_WAIT;
> > +retry:
> > p = mempool_alloc(bs->bio_pool, gfp_mask);
> > front_pad = bs->front_pad;
> > inline_vecs = BIO_INLINE_VECS;
> > }
> >
> > if (unlikely(!p))
> > - return NULL;
> > + goto err;
> >
> > bio = p + front_pad;
> > bio_init(bio);
> > @@ -351,6 +393,19 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
> > nr_iovecs, struct bio_set *bs)
> >
> > err_free:
> > mempool_free(p, bs->bio_pool);
> > +err:
> > + if (gfp_mask != saved_gfp) {
> > + gfp_mask = saved_gfp;
> > +
> > + spin_lock(>rescue_lock);
> > + bio_list_merge(>rescue_list, current->bio_list);
> > + bio_list_init(current->bio_list);
> > + spin_unlock(>rescue_lock);
> > +
> > + queue_work(bs->rescue_workqueue, >rescue_work);
> > + goto retry;
> > + }
>
> I wonder whether it would be easier to follow if this part is in-line
> where retry: is. All that needs to be duplicated is single
> mempool_alloc() call, right?
Actually, what might be better than both of those approaches is shoving
that code into another function. Then it's just:
if (gfp_mask != saved_gfp) {
gfp_mask = saved_gfp;
shovel_bios_to_rescuer();
goto retry;
}
> Overall, I *think* this is correct but need to think more about it to
> be sure.
Please do. As much time as I've spent staring at this kind of stuff,
I'm pretty sure I've got it correct but it still makes my head hurt to
work out all the various possible deadlocks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: multitouch: Remove the redundant touch state
On Wed, 22 Aug 2012, Henrik Rydberg wrote:
> With the input_mt_sync_frame() function in place, there is no longer
> any need to keep the full touch state in the driver. This patch
> removes the slot state and replaces the lookup code with the input-mt
> equivalent. The initialization code is moved to mt_input_configured(),
> to make sure the full HID report has been seen.
>
> Signed-off-by: Henrik Rydberg
> ---
> Hi Benjamin,
>
> Maybe this patch works better? It has received limited testing so far.
What is the status of this patch please? Henrik, Benjamin?
>
> Henrik
>
> drivers/hid/hid-multitouch.c | 133
> +++
> 1 file changed, 46 insertions(+), 87 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index c400d90..dc08a4e 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -56,7 +56,6 @@ struct mt_slot {
> __s32 x, y, p, w, h;
> __s32 contactid;/* the device ContactID assigned to this slot */
> bool touch_state; /* is the touch valid? */
> - bool seen_in_this_frame;/* has this slot been updated */
> };
>
> struct mt_class {
> @@ -93,7 +92,7 @@ struct mt_device {
> * 1 means we should use a serial protocol
> * > 1 means hybrid (multitouch) protocol */
> bool curvalid; /* is the current contact valid? */
> - struct mt_slot *slots;
> + unsigned mt_flags; /* flags to pass to input-mt */
> };
>
> /* classes of device behavior */
> @@ -134,25 +133,6 @@ static int cypress_compute_slot(struct mt_device *td)
> return -1;
> }
>
> -static int find_slot_from_contactid(struct mt_device *td)
> -{
> - int i;
> - for (i = 0; i < td->maxcontacts; ++i) {
> - if (td->slots[i].contactid == td->curdata.contactid &&
> - td->slots[i].touch_state)
> - return i;
> - }
> - for (i = 0; i < td->maxcontacts; ++i) {
> - if (!td->slots[i].seen_in_this_frame &&
> - !td->slots[i].touch_state)
> - return i;
> - }
> - /* should not occurs. If this happens that means
> - * that the device sent more touches that it says
> - * in the report descriptor. It is ignored then. */
> - return -1;
> -}
> -
> static struct mt_class mt_classes[] = {
> { .name = MT_CLS_DEFAULT,
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP },
> @@ -319,24 +299,16 @@ static int mt_input_mapping(struct hid_device *hdev,
> struct hid_input *hi,
> * We need to ignore fields that belong to other collections
> * such as Mouse that might have the same GenericDesktop usages. */
> if (field->application == HID_DG_TOUCHSCREEN)
> - set_bit(INPUT_PROP_DIRECT, hi->input->propbit);
> + td->mt_flags |= INPUT_MT_DIRECT;
> else if (field->application != HID_DG_TOUCHPAD)
> return 0;
>
> - /* In case of an indirect device (touchpad), we need to add
> - * specific BTN_TOOL_* to be handled by the synaptics xorg
> - * driver.
> - * We also consider that touchscreens providing buttons are touchpads.
> + /*
> + * Model touchscreens providing buttons as touchpads.
>*/
> if (field->application == HID_DG_TOUCHPAD ||
> - (usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON ||
> - cls->is_indirect) {
> - set_bit(INPUT_PROP_POINTER, hi->input->propbit);
> - set_bit(BTN_TOOL_FINGER, hi->input->keybit);
> - set_bit(BTN_TOOL_DOUBLETAP, hi->input->keybit);
> - set_bit(BTN_TOOL_TRIPLETAP, hi->input->keybit);
> - set_bit(BTN_TOOL_QUADTAP, hi->input->keybit);
> - }
> + (usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON)
> + td->mt_flags |= INPUT_MT_POINTER;
>
> /* eGalax devices provide a Digitizer.Stylus input which overrides
>* the correct Digitizers.Finger X/Y ranges.
> @@ -353,8 +325,6 @@ static int mt_input_mapping(struct hid_device *hdev,
> struct hid_input *hi,
> EV_ABS, ABS_MT_POSITION_X);
> set_abs(hi->input, ABS_MT_POSITION_X, field,
> cls->sn_move);
> - /* touchscreen emulation */
> - set_abs(hi->input, ABS_X, field, cls->sn_move);
> mt_store_field(usage, td, hi);
> td->last_field_index = field->index;
> return 1;
> @@ -363,8 +333,6 @@ static int mt_input_mapping(struct hid_device *hdev,
> struct hid_input *hi,
> EV_ABS, ABS_MT_POSITION_Y);
> set_abs(hi->input, ABS_MT_POSITION_Y, field,
> cls->sn_move);
> - /* touchscreen emulation */
> -
[PATCH 01/13] perf tools: include wrapper for magic.h
perf is currently including magic.h directly from the kernel. If the glibc magic.h is also included, this leads to warnings that the constants are redefined. This happens on some systems (e.g. Android). Redefinition errors on Android: In file included from util/util.h:79:0, from util/cache.h:5, from util/abspath.c:1: util/../../../include/linux/magic.h:5:0: error: "AFFS_SUPER_MAGIC" redefined [-Werror] bionic/libc/include/sys/vfs.h:53:0: note: this is the location of the previous definition util/../../../include/linux/magic.h:19:0: error: "EFS_SUPER_MAGIC" redefined [-Werror] bionic/libc/include/sys/vfs.h:61:0: note: this is the location of the previous definition util/../../../include/linux/magic.h:26:0: error: "HPFS_SUPER_MAGIC" redefined [-Werror] bionic/libc/include/sys/vfs.h:67:0: note: this is the location of the previous definition Only two constants from magic.h are used by perf (DEBUGFS_MAGIC and SYSFS_MAGIC). This fix provides a wrapper for magic.h that includes only these constants instead of including the kernel header file directly. Signed-off-by: Irina Tirdea --- tools/perf/Makefile |1 + tools/perf/util/include/linux/magic.h | 12 tools/perf/util/util.h|2 +- 3 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tools/perf/util/include/linux/magic.h diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 6bd888d..58304d9 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -264,6 +264,7 @@ LIB_H += util/include/linux/ctype.h LIB_H += util/include/linux/kernel.h LIB_H += util/include/linux/list.h LIB_H += util/include/linux/export.h +LIB_H += util/include/linux/magic.h LIB_H += util/include/linux/poison.h LIB_H += util/include/linux/prefetch.h LIB_H += util/include/linux/rbtree.h diff --git a/tools/perf/util/include/linux/magic.h b/tools/perf/util/include/linux/magic.h new file mode 100644 index 000..58b64ed --- /dev/null +++ b/tools/perf/util/include/linux/magic.h @@ -0,0 +1,12 @@ +#ifndef _PERF_LINUX_MAGIC_H_ +#define _PERF_LINUX_MAGIC_H_ + +#ifndef DEBUGFS_MAGIC +#define DEBUGFS_MAGIC 0x64626720 +#endif + +#ifndef SYSFS_MAGIC +#define SYSFS_MAGIC0x62656572 +#endif + +#endif diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h index 00a93a9..d306ec1f 100644 --- a/tools/perf/util/util.h +++ b/tools/perf/util/util.h @@ -75,7 +75,7 @@ #include #include #include -#include "../../../include/linux/magic.h" +#include #include "types.h" #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 4/9] pktcdvd: Switch to bio_kmalloc()
On Tue, Aug 28, 2012 at 01:32:47PM -0700, Tejun Heo wrote: > On Tue, Aug 28, 2012 at 10:37:31AM -0700, Kent Overstreet wrote: > > This is prep work for killing bi_destructor - previously, pktcdvd had > > its own pkt_bio_alloc which was basically duplication bio_kmalloc(), > > necessitating its own bi_destructor implementation. > > How was this tested? Hasn't been yet, but I'm getting a new test machine in the next day or so (and also the patch is a lot smaller since the bio_reset() changes you suggested). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 06:06:10PM -0400, Vivek Goyal wrote: > On Tue, Aug 28, 2012 at 10:37:36AM -0700, Kent Overstreet wrote: > > Previously, if we ever try to allocate more than once from the same bio > > set while running under generic_make_request() (i.e. a stacking block > > driver), we risk deadlock. > > > > This is because of the code in generic_make_request() that converts > > recursion to iteration; any bios we submit won't actually be submitted > > (so they can complete and eventually be freed) until after we return - > > this means if we allocate a second bio, we're blocking the first one > > from ever being freed. > > > > Thus if enough threads call into a stacking block driver at the same > > time with bios that need multiple splits, and the bio_set's reserve gets > > used up, we deadlock. > > Hi Kent, > > So above deadlock possibility arises only if multiple threads are doing > multiple splits from same pool and all the threads get blocked on mempool > and don't return from ->make_request function. > > Is there any existing driver in the tree which can cause this deadlock or > it becomes a possibility only when splitting and bcache code shows up? It is emphatically possible with dm, though you would probably need a pathalogical configuration of your targets for it to be possible in practice - at least with the targets currently commonly in use. With most of the newer dm targets coming down the pipe I expect it should be possible under real world configurations, with the caveat that under that kind of memory pressure in practice many other things will fall over first. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/13] perf tools: replace mempcpy with memcpy
mempcpy is not supported by bionic in Android
and will lead to compilation errors.
Replacing mempcpy with memcpy so it will work in Android.
Signed-off-by: Irina Tirdea
---
tools/perf/util/target.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/target.c b/tools/perf/util/target.c
index 051eaa6..065528b 100644
--- a/tools/perf/util/target.c
+++ b/tools/perf/util/target.c
@@ -117,8 +117,8 @@ int perf_target__strerror(struct perf_target
*target, int errnum,
if (err != buf) {
size_t len = strlen(err);
- char *c = mempcpy(buf, err, min(buflen - 1, len));
- *c = '\0';
+ memcpy(buf, err, min(buflen - 1, len));
+ *(buf + min(buflen - 1, len)) = '\0';
}
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 14/16] sched: make __update_entity_runnable_avg() fast
Applied, Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/9] block: Add bio_reset()
On Tue, Aug 28, 2012 at 01:31:48PM -0700, Tejun Heo wrote:
> Hello, Kent.
>
> On Tue, Aug 28, 2012 at 10:37:30AM -0700, Kent Overstreet wrote:
> > Reusing bios is something that's been highly frowned upon in the past,
> > but driver code keeps doing it anyways. If it's going to happen anyways,
> > we should provide a generic method.
> >
> > This'll help with getting rid of bi_destructor - drivers/block/pktcdvd.c
> > was open coding it, by doing a bio_init() and resetting bi_destructor.
>
> Better to explain why some bio fields are re-ordered and why that
> shouldn't make things worse cacheline-wise?
Well it may (struct bio is what, 3 or 4 cachelines now?) but even on
ridiculous million iop devices struct bio just isn't hot enough for this
kind of stuff to show up in the profiles... and I've done enough
profiling to be pretty confident of that.
So um, if there was anything to say performance wise I would, but to me
it seems more that there isn't.
(pruning struct bio would have more of an effect performance wise, which
you know is something I'd like to do.)
>
> > +void bio_reset(struct bio *bio)
> > +{
>
> Function comment explaining what it does and why it does what it does
> with integrity / bi_css / whatnot?
Yeah, good idea.
>
> > + unsigned long flags = bio->bi_flags & (~0UL << BIO_RESET_BITS);
> > +
> > + if (bio_integrity(bio))
> > + bio_integrity_free(bio, bio->bi_pool);
> > +
> > + bio_disassociate_task(bio);
>
> Is this desirable? Why?
*twitch* I should've thought more when I made that change.
It occurs to me now that we specifically talked about that and decided
to do it the other way - when I changed that I was just looking at
bio_free() and decided they needed to be symmetrical.
I still think they should be symmetrical, but if that's true bi_ioc and
bi_css need to be moved, and also bio_disassociate_task() should be
getting called from bio_free(), not bio_put().
Were you the one that added that call? I know you've been working on
that area of the code recently. Sticking it in bio_put() instead of
bio_free() seems odd to be, and they're completely equivalent now that
bio_free() is only called from bio_put() (save one instance I should
probably fix).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next] mei: add lynx point pci device ids
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw.h |2 ++
drivers/misc/mei/main.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index b3b4c6d..9700532 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -80,6 +80,8 @@
#define MEI_DEV_ID_PPT_2 0x1CBA /* Panther Point */
#define MEI_DEV_ID_PPT_3 0x1DBA /* Panther Point */
+#define MEI_DEV_ID_LPT0x8C3A /* Lynx Point */
+#define MEI_DEV_ID_LPT_LP 0x9C3A /* Lynx Point LP */
/*
* MEI HW Section
*/
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index d6fe278..ae2cd0d 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -77,6 +77,8 @@ static DEFINE_PCI_DEVICE_TABLE(mei_pci_tbl) = {
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, MEI_DEV_ID_PPT_1)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, MEI_DEV_ID_PPT_2)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, MEI_DEV_ID_PPT_3)},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, MEI_DEV_ID_LPT)},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, MEI_DEV_ID_LPT_LP)},
/* required last entry */
{0, }
--
1.7.4.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 01/16] sched: track the runnable average on a per-task entitiy basis
On Fri, Aug 24, 2012 at 1:20 AM, Namhyung Kim wrote:
> Hi,
>
> Just typos below..
>
Applied, Thanks.
> On Thu, 23 Aug 2012 07:14:23 -0700, > From: Paul Turner
>>
>> Instead of tracking averaging the load parented by a cfs_rq, we can track
>> entity load directly. With the load for a given cfs_rq then being the
>> sum of
>> its children.
>>
>> To do this we represent the historical contribution to runnable average
>> within each
>> trailing 1024us of execution as the coefficients of a geometric series.
>>
>> We can express this for a given task t as:
>> runnable_sum(t) = \Sum u_i * y^i, runnable_avg_period(t) = \Sum 1024 *
>> y^i
>> load(t) = weight_t * runnable_sum(t) / runnable_avg_period(t)
>>
>> Where: u_i is the usage in the last i`th 1024us period (approximately
>> 1ms) ~ms
>> and y is chosen such that y^k = 1/2. We currently choose k to be 32
>> which
>> roughly translates to about a sched period.
>>
>> Signed-off-by: Paul Turner
>> Reviewed-by: Ben Segall
>> ---
>> include/linux/sched.h | 13 +
>> kernel/sched/core.c |5 ++
>> kernel/sched/debug.c |4 ++
>> kernel/sched/fair.c | 128
>> +
>> 4 files changed, 150 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index f3eebc1..f553da9 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1139,6 +1139,16 @@ struct load_weight {
>> unsigned long weight, inv_weight;
>> };
>>
>> +struct sched_avg {
>> + /*
>> + * These sums represent an infinite geometric series and so are
>> bound
>> + * above by 1024/(1-y). Thus we only need a u32 to store them for
>> for all
>> + * choices of y < 1-2^(-32)*1024.
>> + */
>> + u32 runnable_avg_sum, runnable_avg_period;
>> + u64 last_runnable_update;
>> +};
>> +
>> #ifdef CONFIG_SCHEDSTATS
>> struct sched_statistics {
>> u64 wait_start;
>> @@ -1199,6 +1209,9 @@ struct sched_entity {
>> /* rq "owned" by this entity/group: */
>> struct cfs_rq *my_q;
>> #endif
>> +#ifdef CONFIG_SMP
>> + struct sched_avgavg;
>> +#endif
>> };
>>
>> struct sched_rt_entity {
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 78d9c96..fcc3cad 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1556,6 +1556,11 @@ static void __sched_fork(struct task_struct *p)
>> p->se.vruntime = 0;
>> INIT_LIST_HEAD(>se.group_node);
>>
>> +#ifdef CONFIG_SMP
>> + p->se.avg.runnable_avg_period = 0;
>> + p->se.avg.runnable_avg_sum = 0;
>> +#endif
>> +
>> #ifdef CONFIG_SCHEDSTATS
>> memset(>se.statistics, 0, sizeof(p->se.statistics));
>> #endif
>> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> index 6f79596..61f7097 100644
>> --- a/kernel/sched/debug.c
>> +++ b/kernel/sched/debug.c
>> @@ -85,6 +85,10 @@ static void print_cfs_group_stats(struct seq_file *m,
>> int cpu, struct task_group
>> P(se->statistics.wait_count);
>> #endif
>> P(se->load.weight);
>> +#ifdef CONFIG_SMP
>> + P(se->avg.runnable_avg_sum);
>> + P(se->avg.runnable_avg_period);
>> +#endif
>> #undef PN
>> #undef P
>> }
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 01d3eda..2c53263 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -971,6 +971,125 @@ static inline void update_entity_shares_tick(struct
>> cfs_rq *cfs_rq)
>> }
>> #endif /* CONFIG_FAIR_GROUP_SCHED */
>>
>> +#ifdef CONFIG_SMP
>> +/*
>> + * Approximate:
>> + * val * y^n,where y^32 ~= 0.5 (~1 scheduling period)
>> + */
>> +static __always_inline u64 decay_load(u64 val, u64 n)
>> +{
>> + for (; n && val; n--) {
>> + val *= 4008;
>> + val >>= 12;
>> + }
>> +
>> + return val;
>> +}
>> +
>> +/* We can represent the historical contribution to runnable average as
>> the
>> + * coefficients of a geometric series. To do this we sub-divide our
>> runnable
>> + * history into segments of approximately 1ms (1024us); label the
>> segment that
>> + * occurred N-ms ago p_N, with p_0 corresponding to the current period,
>> e.g.
>> + *
>> + * [<- 1024us ->|<- 1024us ->|<- 1024us ->| ...
>> + * p0p1 p1
>
> Should it be p2 ?
>
>
>> + * (now) (~1ms ago) (~2ms ago)
>> + *
>> + * Let u_i denote the fraction of p_i that the entity was runnable.
>> + *
>> + * We then designate the fractions u_i as our co-efficients, yielding
>> the
>> + * following representation of historical load:
>> + * u_0 + u_1*y + u_2*y^2 + u_3*y^3 + ...
>> + *
>> + * We choose y based on the with of a reasonably scheduling period,
>> fixing:
>> + * y^32 = 0.5
>> + *
>> + * This means that the contribution to load ~32ms ago (u_32) will be
>> weighted
>> + * approximately half as much as the contribution to load within the
>> last ms
>> + * (u_0).
>> + *
>> + * When a period
Re: [RFC PATCH] x86: use new exception_enter()/exception_exit() API in do_device_not_available()
On Wed, Aug 29, 2012 at 12:00:47AM +0300, Sergey Senozhatsky wrote:
> x86: use new exception_enter()/exception_exit() API in
> do_device_not_available()
>
> RCU can be in extended quiescent state when do_device_not_available() called.
>
> [ 676.400274] RCU used illegally from idle CPU!
> [ 676.400274] rcu_scheduler_active = 1, debug_locks = 0
> [ 676.400278] RCU used illegally from extended quiescent state!
> [ 676.400282] 2 locks held by sed/9468:
> [ 676.400285] #0: (>lock){-.-.-.}, at: []
> __schedule+0x1c0/0x992
> [ 676.400304] #1: (rcu_read_lock){.+.+..}, at: []
> cpuacct_charge+0x27/0x1e0
> [ 676.400321]
> [ 676.400329] Call Trace:
> [ 676.400340] [] lockdep_rcu_suspicious+0x109/0x112
> [ 676.400347] [] cpuacct_charge+0x9e/0x1e0
> [ 676.400353] [] ? cpuacct_charge+0x27/0x1e0
> [ 676.400359] [] ? __schedule+0x1c0/0x992
> [ 676.400366] [] update_curr+0x159/0x200
> [ 676.400375] [] ? init_fpu+0x4e/0x8f
> [ 676.400382] [] put_prev_task_fair+0x2a/0xac
> [ 676.400388] [] __schedule+0x398/0x992
> [ 676.400397] [] ? rcu_irq_exit+0x83/0x99
> [ 676.400404] [] ? retint_restore_args+0x13/0x13
> [ 676.400411] [] ? lock_is_held+0x2d/0xa5
> [ 676.400414] [] ? init_fpu+0x4e/0x8f
> [ 676.400417] [] __cond_resched+0x28/0x34
> [ 676.400420] [] _cond_resched+0x2e/0x35
> [ 676.400425] [] kmem_cache_alloc+0x4c/0x1c5
> [ 676.400430] [] ? math_state_restore+0x1f/0xdc
> [ 676.400433] [] init_fpu+0x4e/0x8f
> [ 676.400437] [] math_state_restore+0x2e/0xdc
> [ 676.400440] [] do_device_not_available+0xe/0x10
> [ 676.400445] [] device_not_available+0x1b/0x20
>
>
> Signed-off-by: Sergey Senozhatsky
>
> ---
>
> arch/x86/kernel/traps.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index ab82cbd..dff3e72 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -654,7 +654,9 @@ do_device_not_available(struct pt_regs *regs, long
> error_code)
> return;
> }
> #endif
> + exception_enter(regs);
> math_state_restore(); /* interrupts still off */
> + exception_enter(regs);
Shouldn't that be exception_exit actually?
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] block: Kill bi_destructor
On Tue, Aug 28, 2012 at 01:36:13PM -0700, Tejun Heo wrote: > On Tue, Aug 28, 2012 at 10:37:32AM -0700, Kent Overstreet wrote: > > @@ -385,7 +386,7 @@ struct bio *bio_kmalloc(gfp_t gfp_mask, unsigned int > > nr_iovecs) > > bio->bi_flags |= BIO_POOL_NONE << BIO_POOL_OFFSET; > > bio->bi_max_vecs = nr_iovecs; > > bio->bi_io_vec = bio->bi_inline_vecs; > > - bio->bi_destructor = bio_kmalloc_destructor; > > + bio->bi_pool = NULL; > > Doesn't bio_init() already memset the whole thing? Yes it does, holdover from BIO_KMALLOC_POOL. Dropping it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/13] perf tools: replace mkostemp with mkstemp
mkostemp is only available in glibc. This leads to compile
error in Android, since bionic is derived from BSD.
Replacing mkostemp with mkstemp. mkstemp is available on
both glibc and bionic.
Signed-off-by: Irina Tirdea
---
tools/perf/util/dso-test-data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/dso-test-data.c b/tools/perf/util/dso-test-data.c
index 541cdc7..c6caede 100644
--- a/tools/perf/util/dso-test-data.c
+++ b/tools/perf/util/dso-test-data.c
@@ -23,7 +23,7 @@ static char *test_file(int size)
int fd, i;
unsigned char *buf;
-fd = mkostemp(templ, O_CREAT|O_WRONLY|O_TRUNC);
+fd = mkstemp(templ);
buf = malloc(size);
if (!buf) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/13] perf tools: replace on_exit with atexit
on_exit() is only available in new versions of glibc.
Using on_exit on Android leads to errors at compile time.
Replacing on_exit with its more portable version atexit.
This leads to using a global variable since on_exit supports
sending a parameters while atexit does not.
Signed-off-by: Irina Tirdea
---
tools/perf/builtin-record.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3fc9bf9..f5daedf 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -66,6 +66,9 @@ struct perf_record {
off_tpost_processing_offset;
};
+/* for atexit */
+static struct perf_record *saved_rec;
+
static void advance_output(struct perf_record *rec, size_t size)
{
rec->bytes_written += size;
@@ -143,9 +146,9 @@ static void sig_handler(int sig)
signr = sig;
}
-static void perf_record__sig_exit(int exit_status __maybe_unused, void *arg)
+static void perf_record__sig_exit(void)
{
-struct perf_record *rec = arg;
+struct perf_record *rec = saved_rec;
int status;
if (rec->evlist->workload.pid > 0) {
@@ -335,9 +338,9 @@ static int process_buildids(struct perf_record *rec)
size, _id__mark_dso_hit_ops);
}
-static void perf_record__exit(int status __maybe_unused, void *arg)
+static void perf_record__exit(void)
{
-struct perf_record *rec = arg;
+struct perf_record *rec = saved_rec;
if (!rec->opts.pipe_output) {
rec->session->header.data_size += rec->bytes_written;
@@ -424,7 +427,8 @@ static int __cmd_record(struct perf_record *rec,
int argc, const char **argv)
rec->page_size = sysconf(_SC_PAGE_SIZE);
-on_exit(perf_record__sig_exit, rec);
+saved_rec = rec;
+atexit(perf_record__sig_exit);
signal(SIGCHLD, sig_handler);
signal(SIGINT, sig_handler);
signal(SIGUSR1, sig_handler);
@@ -508,7 +512,7 @@ static int __cmd_record(struct perf_record *rec,
int argc, const char **argv)
/*
* perf_session__delete(session) will be called at perf_record__exit()
*/
-on_exit(perf_record__exit, rec);
+atexit(perf_record__exit);
if (opts->pipe_output) {
err = perf_header__write_pipe(output);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Aug 28, 2012 at 10:37:36AM -0700, Kent Overstreet wrote: > Previously, if we ever try to allocate more than once from the same bio > set while running under generic_make_request() (i.e. a stacking block > driver), we risk deadlock. > > This is because of the code in generic_make_request() that converts > recursion to iteration; any bios we submit won't actually be submitted > (so they can complete and eventually be freed) until after we return - > this means if we allocate a second bio, we're blocking the first one > from ever being freed. > > Thus if enough threads call into a stacking block driver at the same > time with bios that need multiple splits, and the bio_set's reserve gets > used up, we deadlock. Hi Kent, So above deadlock possibility arises only if multiple threads are doing multiple splits from same pool and all the threads get blocked on mempool and don't return from ->make_request function. Is there any existing driver in the tree which can cause this deadlock or it becomes a possibility only when splitting and bcache code shows up? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/9] block: Add bio_clone_bioset(), bio_clone_kmalloc()
On Tue, Aug 28, 2012 at 01:44:01PM -0700, Tejun Heo wrote:
> On Tue, Aug 28, 2012 at 10:37:34AM -0700, Kent Overstreet wrote:
> > +static inline struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> > +{
> > + return bio_clone_bioset(bio, gfp_mask, fs_bio_set);
> > +}
> > +
> ...
> > +static inline struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t
> > gfp_mask)
> > +{
> > + return bio_clone_bioset(bio, gfp_mask, NULL);
> > +
> > +}
>
> Do we really need these wrappers? I'd prefer requiring users to
> explicit choose @bioset when cloning.
bio_clone() is an existing api, I agree but I'd prefer to convert
existing users in a separate patch and when I do that I want to spend
some time actually looking at the existing code instead of doing the
conversion blindly (at least some of the existing users are incorrect
and I'll have to add bio_sets for them).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/13] perf tools: fix non-void function without return statement
thread_func in builtin-sched.c has an internal loop and
never returns. The only return from this thread are
BUG_ON calls in case return values are not 0.
The compiler on Android complains that the function
needs to return a non-void value. Adding the noreturn
function attribute to fix this error.
Error in Android:
target C: perf <= builtin-sched.c
hardware/intel/linu/tools/perf/builtin-sched.c: In function 'thread_func':
hardware/intel/linux/tools/perf/builtin-sched.c:476: error: no return
statement in function returning non-void
Signed-off-by: Irina Tirdea
---
tools/perf/builtin-sched.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 3d3cab46..da293b8 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -439,7 +439,7 @@ static u64 get_cpu_usage_nsec_self(int fd)
return runtime;
}
-static void *thread_func(void *ctx)
+static __attribute__ ((noreturn)) void *thread_func(void *ctx)
{
struct task_desc *this_task = ctx;
u64 cpu_usage_0, cpu_usage_1;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/13] perf tools: include missing pthread.h header
pthread variables are used in some files without explicitely including pthread.h. This leads to compile errors on Android. e.g.: in annotate.h, error: unknown type name 'pthread_mutex_t' Including pthread.h explicitely in files that use it to have all definitions included. Signed-off-by: Irina Tirdea --- tools/perf/perf.c |1 + tools/perf/util/annotate.h |1 + 2 files changed, 2 insertions(+) diff --git a/tools/perf/perf.c b/tools/perf/perf.c index e7840e5..fb8578c 100644 --- a/tools/perf/perf.c +++ b/tools/perf/perf.c @@ -14,6 +14,7 @@ #include "util/run-command.h" #include "util/parse-events.h" #include "util/debugfs.h" +#include const char perf_usage_string[] = "perf [--version] [--help] COMMAND [ARGS]"; diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h index d6f1b4b..0c81586 100644 --- a/tools/perf/util/annotate.h +++ b/tools/perf/util/annotate.h @@ -7,6 +7,7 @@ #include "symbol.h" #include #include +#include struct ins; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/13] perf tools: fix missing winsize definition
In Android, struct winsize is not defined in
the headers already included in help.c.
This leads to a compile error.
Including termios.h fixes the compilation error
since it defines struct winsize.
Signed-off-by: Irina Tirdea
---
tools/perf/util/help.c |1 +
tools/perf/util/top.h |1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/help.c b/tools/perf/util/help.c
index 6f2975a..4fa764d 100644
--- a/tools/perf/util/help.c
+++ b/tools/perf/util/help.c
@@ -3,6 +3,7 @@
#include "exec_cmd.h"
#include "levenshtein.h"
#include "help.h"
+#include
void add_cmdname(struct cmdnames *cmds, const char *name, size_t len)
{
diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
index 33347ca..86ff1b1 100644
--- a/tools/perf/util/top.h
+++ b/tools/perf/util/top.h
@@ -5,6 +5,7 @@
#include "types.h"
#include
#include
+#include
struct perf_evlist;
struct perf_evsel;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/13] perf tools: include basename for non-glibc systems
perf uses the glibc version of basename(), by defining _GNU_SOURCE, including string.h and not including libgen.h. The glibc version of basename is better than the POSIX version since it does not modify its argument. Android has only one version of basename which is defined in libgen.h. This version is the same as the glibc version. Error on Android: util/annotate.c: In function 'symbol__annotate_printf': util/annotate.c:503:3: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration] util/annotate.c:503:3: error: nested extern declaration of 'basename' [-Werror=nested-externs] util/annotate.c:503:14: error: assignment makes pointer from integer without a cast [-Werror] On Android libgen.h should be included to define basename. Signed-off-by: Irina Tirdea --- tools/perf/util/symbol.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h index fc4b1e6..d3b330c 100644 --- a/tools/perf/util/symbol.h +++ b/tools/perf/util/symbol.h @@ -10,6 +10,9 @@ #include #include #include +#if defined(__BIONIC__) +#include +#endif #ifndef NO_LIBELF_SUPPORT #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 6/9] block: Consolidate bio_alloc_bioset(), bio_kmalloc()
On Tue, Aug 28, 2012 at 01:41:48PM -0700, Tejun Heo wrote: > Hello, Kent. > > On Tue, Aug 28, 2012 at 10:37:33AM -0700, Kent Overstreet wrote: > > v7: Re-add dropped comments, improv patch description > > I don't think you did the former part. Other than that looks good to > me. I folded them into the bio_alloc_bioset() comments - so all the information that was there previously should still be there, just centralized. That good enough for your acked-by? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/13] perf tools: fix ALIGN redefinition in system headers
On some systems (e.g. Android), ALIGN is defined in
system headers as ALIGN(p). The definition of ALIGN used
in perf takes 2 parameters: ALIGN(x,a). This leads to
redefinition conflicts.
Redefinition error on Android:
In file included from util/include/linux/list.h:1:0,
from util/callchain.h:5,
from util/hist.h:6,
from util/session.h:4,
from util/build-id.h:4,
from util/annotate.c:11:
util/include/linux/kernel.h:11:0: error: "ALIGN" redefined [-Werror]
bionic/libc/include/sys/param.h:38:0: note: this is the location of
the previous definition
Conflics with system defined ALIGN in Android:
util/event.c: In function 'perf_event__synthesize_comm':
util/event.c:115:32: error: macro "ALIGN" passed 2 arguments, but takes just 1
util/event.c:115:9: error: 'ALIGN' undeclared (first use in this function)
util/event.c:115:9: note: each undeclared identifier is reported only once for
each function it appears in
In order to avoid this redefinition, ALIGN is renamed to PERF_ALIGN.
Signed-off-by: Irina Tirdea
---
tools/perf/util/event.c| 10 +-
tools/perf/util/event.h|2 +-
tools/perf/util/header.c | 16
tools/perf/util/include/linux/kernel.h |4 ++--
tools/perf/util/session.c |4 ++--
tools/perf/util/symbol.c |2 +-
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 3a0f1a5..aee4ddf 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -112,7 +112,7 @@ static pid_t perf_event__synthesize_comm(struct
perf_tool *tool,
event->comm.header.type = PERF_RECORD_COMM;
size = strlen(event->comm.comm) + 1;
-size = ALIGN(size, sizeof(u64));
+size = PERF_ALIGN(size, sizeof(u64));
memset(event->comm.comm + size, 0, machine->id_hdr_size);
event->comm.header.size = (sizeof(event->comm) -
(sizeof(event->comm.comm) - size) +
@@ -143,7 +143,7 @@ static pid_t perf_event__synthesize_comm(struct
perf_tool *tool,
sizeof(event->comm.comm));
size = strlen(event->comm.comm) + 1;
-size = ALIGN(size, sizeof(u64));
+size = PERF_ALIGN(size, sizeof(u64));
memset(event->comm.comm + size, 0, machine->id_hdr_size);
event->comm.header.size = (sizeof(event->comm) -
(sizeof(event->comm.comm) - size) +
@@ -222,7 +222,7 @@ static int
perf_event__synthesize_mmap_events(struct perf_tool *tool,
size = strlen(execname);
execname[size - 1] = '\0'; /* Remove \n */
memcpy(event->mmap.filename, execname, size);
-size = ALIGN(size, sizeof(u64));
+size = PERF_ALIGN(size, sizeof(u64));
event->mmap.len -= event->mmap.start;
event->mmap.header.size = (sizeof(event->mmap) -
(sizeof(event->mmap.filename) - size));
@@ -272,7 +272,7 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
if (pos->dso->kernel)
continue;
-size = ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
+size = PERF_ALIGN(pos->dso->long_name_len + 1, sizeof(u64));
event->mmap.header.type = PERF_RECORD_MMAP;
event->mmap.header.size = (sizeof(event->mmap) -
(sizeof(event->mmap.filename) - size));
@@ -477,7 +477,7 @@ int perf_event__synthesize_kernel_mmap(struct
perf_tool *tool,
map = machine->vmlinux_maps[MAP__FUNCTION];
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
"%s%s", mmap_name, symbol_name) + 1;
-size = ALIGN(size, sizeof(u64));
+size = PERF_ALIGN(size, sizeof(u64));
event->mmap.header.type = PERF_RECORD_MMAP;
event->mmap.header.size = (sizeof(event->mmap) -
(sizeof(event->mmap.filename) - size) + machine->id_hdr_size);
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 0e088d0..21b99e7 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -101,7 +101,7 @@ struct perf_sample {
struct build_id_event {
struct perf_event_header header;
pid_t pid;
-u8 build_id[ALIGN(BUILD_ID_SIZE, sizeof(u64))];
+u8 build_id[PERF_ALIGN(BUILD_ID_SIZE, sizeof(u64))];
char filename[];
};
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 1e5b6aa..7f8631f 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -128,7 +128,7 @@ static int do_write_string(int fd, const char *str)
int ret;
olen = strlen(str) + 1;
-len = ALIGN(olen, NAME_ALIGN);
+len = PERF_ALIGN(olen, NAME_ALIGN);
/* write len, incl. \0 */
ret = do_write(fd, , sizeof(len));
@@ -219,7 +219,7 @@ static int __dsos__write_buildid_table(struct
list_head *head, pid_t pid,
if (!pos->hit)
continue;
len = pos->long_name_len + 1;
-len =
[PATCH 04/13] perf tools: include __WORDSIZE definition
__WORDSIZE is GLibC-specific and is not defined on all systems or glibc versions (e.g. Android's bionic does not define it). In file included from util/include/linux/bitmap.h:5:0, from util/header.h:10, from util/session.h:6, from util/build-id.h:4, from util/annotate.c:11: util/include/linux/bitops.h: In function 'set_bit': util/include/linux/bitops.h:25:12: error: '__WORDSIZE' undeclared (first use in this function) util/include/linux/bitops.h:25:12: note: each undeclared identifier is reported only once for each function it appears in util/include/linux/bitops.h:23:51: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter] util/include/linux/bitops.h: In function 'clear_bit': util/include/linux/bitops.h:30:12: error: '__WORDSIZE' undeclared (first use in this function) util/include/linux/bitops.h:28:53: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter] In file included from util/header.h:10:0, from util/session.h:6, from util/build-id.h:4, from util/annotate.c:11: util/include/linux/bitmap.h: In function 'bitmap_zero': util/include/linux/bitmap.h:22:6: error: '__WORDSIZE' undeclared (first use in this function) Defining __WORDSIZE in perf's headers if it is not already defined. Signed-off-by: Irina Tirdea --- tools/perf/util/include/linux/bitops.h |9 + 1 file changed, 9 insertions(+) diff --git a/tools/perf/util/include/linux/bitops.h b/tools/perf/util/include/linux/bitops.h index 587a230..91779ec 100644 --- a/tools/perf/util/include/linux/bitops.h +++ b/tools/perf/util/include/linux/bitops.h @@ -5,6 +5,15 @@ #include #include +#ifndef __WORDSIZE +#if defined(__x86_64__) +# define __WORDSIZE 64 +#endif +#if defined(__i386__) || defined(__arm__) +# define __WORDSIZE 32 +#endif +#endif + #define BITS_PER_LONG __WORDSIZE #define BITS_PER_BYTE 8 #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: tegra: add const to of_device_id.data's structure
On Sun, 2012-08-26 at 21:25 -0700, Stephen Warren wrote: > On 08/26/2012 03:14 AM, Laxman Dewangan wrote: > > The membe "data" of structure of_device_id is changed to const > > pointer. Hence initializing this with const type data. > > This will fix the compilation warning like > > drivers/dma/tegra20-apb-dma.c:1217:9: warning: assignment discards 'const' > > qualifier from > > pointer target type [enabled by default] > > > > This warning came after the change > > - > > commit 98d7bbb9929bcc14e11ac8a55245a4f2dc174e17 > > Author: Uwe Kleine-König > > of: add const to struct *of_device_id.data > > - > > Acked-by: Stephen Warren Acked-by: Vinod Koul -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/13] perf tools: drop asm/byteorder.h wrapper
Wrapping asm/byteorder.h will also replace the glibc header,
not only the kernel one. asm/byteorder.h further includes
architecture dependent headers that define endianess.
Some systems (e.g. Android) need constant definitions that
depend on endianess (e.g. __constant_htonl).
In file included from bionic/libc/include/netinet/tcp.h:32:0,
from kernel/intel/tools/perf/util/util.h:74,
from kernel/intel/tools/perf/util/cache.h:5,
from kernel/intel/tools/perf/util/abspath.c:1:
bionic/libc/kernel/common/linux/tcp.h:61:2:
error: enumerator value for 'TCP_FLAG_CWR' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:62:2:
error: enumerator value for 'TCP_FLAG_ECE' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:63:2:
error: enumerator value for 'TCP_FLAG_URG' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:64:2:
error: enumerator value for 'TCP_FLAG_ACK' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:65:2:
error: enumerator value for 'TCP_FLAG_PSH' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:66:2:
error: enumerator value for 'TCP_FLAG_RST' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:67:2:
error: enumerator value for 'TCP_FLAG_SYN' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:68:2:
error: enumerator value for 'TCP_FLAG_FIN' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:69:2:
error: enumerator value for 'TCP_RESERVED_BITS' is not an integer constant
bionic/libc/kernel/common/linux/tcp.h:71:1:
error: enumerator value for 'TCP_DATA_OFFSET' is not an integer constant
Drop this wrapper and use swab.h. glibc byteorder.h header
already includes asm/types.h and swab.h. Using swab.h
wrapper to do the work from byteorder.h should be enough.
Signed-off-by: Irina Tirdea
---
tools/perf/Makefile |1 -
tools/perf/util/include/asm/byteorder.h |2 --
tools/perf/util/include/asm/swab.h |2 +-
tools/perf/util/parse-events.l |1 +
tools/perf/util/util.h |1 +
5 files changed, 3 insertions(+), 4 deletions(-)
delete mode 100644 tools/perf/util/include/asm/byteorder.h
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 58304d9..81ea120 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -273,7 +273,6 @@ LIB_H += util/include/linux/types.h
LIB_H += util/include/linux/linkage.h
LIB_H += util/include/asm/asm-offsets.h
LIB_H += util/include/asm/bug.h
-LIB_H += util/include/asm/byteorder.h
LIB_H += util/include/asm/hweight.h
LIB_H += util/include/asm/swab.h
LIB_H += util/include/asm/system.h
diff --git a/tools/perf/util/include/asm/byteorder.h
b/tools/perf/util/include/asm/byteorder.h
deleted file mode 100644
index b722abe..000
--- a/tools/perf/util/include/asm/byteorder.h
+++ /dev/null
@@ -1,2 +0,0 @@
-#include
-#include "../../../../include/linux/swab.h"
diff --git a/tools/perf/util/include/asm/swab.h
b/tools/perf/util/include/asm/swab.h
index ed53894..e1d3ae0 100644
--- a/tools/perf/util/include/asm/swab.h
+++ b/tools/perf/util/include/asm/swab.h
@@ -1 +1 @@
-/* stub */
+#include "../../../../include/linux/swab.h"
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 2c0d006..73d123b 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -7,6 +7,7 @@
%{
#include
#include "../perf.h"
+#include
#include "parse-events-bison.h"
#include "parse-events.h"
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index d306ec1f..f6716be 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -78,6 +78,7 @@
#include
#include "types.h"
#include
+#include
extern const char *graph_line;
extern const char *graph_dotted_line;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/13] Porting perf to Android
Hi, This is a set of patches to port perf to Android. My approach is to include missing functions in Android (like getline, getsid, etc). I am currently working on upstreaming these to Google. With the missing functionality added to bionic, this compiles on latest Android tree (JellyBean). This will make perf compile, but there are still fixes needed at runtime which I am currently working on. I have seen that another patch that ports perf to Android was recently submitted to this list. The approach is different and there are also changes that do not overlap. If the other patch will be merged first, I will rebase my work on top of it. Thank you, Irina -- Irina Tirdea (13): perf tools: include wrapper for magic.h perf tools: update types definitions for Android perf tools: drop asm/byteorder.h wrapper perf tools: include __WORDSIZE definition perf tools: fix ALIGN redefinition in system headers perf tools: include basename for non-glibc systems perf tools: fix missing winsize definition perf tools: Use __maybe_used for unused variables perf tools: include missing pthread.h header perf tools: fix non-void function without return statement perf tools: replace mempcpy with memcpy perf tools: replace on_exit with atexit perf tools: replace mkostemp with mkstemp tools/perf/Makefile |2 +- tools/perf/bench/bench.h |2 +- tools/perf/bench/mem-memcpy.c|2 +- tools/perf/bench/mem-memset.c|2 +- tools/perf/bench/sched-messaging.c |2 +- tools/perf/bench/sched-pipe.c|4 +- tools/perf/builtin-annotate.c|2 +- tools/perf/builtin-bench.c |2 +- tools/perf/builtin-buildid-cache.c |6 +-- tools/perf/builtin-buildid-list.c|2 +- tools/perf/builtin-diff.c|4 +- tools/perf/builtin-evlist.c |2 +- tools/perf/builtin-help.c|2 +- tools/perf/builtin-inject.c | 20 +++ tools/perf/builtin-kmem.c| 20 +++ tools/perf/builtin-kvm.c |2 +- tools/perf/builtin-list.c|2 +- tools/perf/builtin-lock.c|4 +- tools/perf/builtin-probe.c | 24 - tools/perf/builtin-record.c | 24 + tools/perf/builtin-report.c | 10 ++-- tools/perf/builtin-sched.c | 64 +++ tools/perf/builtin-script.c | 16 +++--- tools/perf/builtin-stat.c| 24 - tools/perf/builtin-test.c|6 +-- tools/perf/builtin-timechart.c | 28 +- tools/perf/builtin-top.c |6 +-- tools/perf/perf.c|1 + tools/perf/ui/browser.c |6 +-- tools/perf/ui/browsers/annotate.c|4 +- tools/perf/ui/gtk/browser.c |4 +- tools/perf/ui/gtk/setup.c|2 +- tools/perf/ui/gtk/util.c |4 +- tools/perf/ui/helpline.c |2 +- tools/perf/ui/helpline.h |8 +-- tools/perf/ui/tui/setup.c|4 +- tools/perf/util/alias.c |2 +- tools/perf/util/annotate.c |6 +-- tools/perf/util/annotate.h | 13 ++--- tools/perf/util/build-id.c | 10 ++-- tools/perf/util/cache.h |6 +-- tools/perf/util/callchain.c |6 +-- tools/perf/util/cgroup.c |4 +- tools/perf/util/config.c |4 +- tools/perf/util/debug.h |8 +-- tools/perf/util/dso-test-data.c |2 +- tools/perf/util/event.c | 28 +- tools/perf/util/event.h |2 +- tools/perf/util/header.c | 84 +++--- tools/perf/util/help.c |3 +- tools/perf/util/hist.c |2 +- tools/perf/util/hist.h | 30 +-- tools/perf/util/include/asm/byteorder.h |2 - tools/perf/util/include/asm/swab.h |2 +- tools/perf/util/include/linux/bitops.h |9 tools/perf/util/include/linux/compiler.h |6 ++- tools/perf/util/include/linux/kernel.h | 15 +- tools/perf/util/include/linux/magic.h| 12 + tools/perf/util/include/linux/types.h| 15 ++ tools/perf/util/intlist.c|6 +-- tools/perf/util/map.h|2 +- tools/perf/util/parse-events-test.c |6 +-- tools/perf/util/parse-events.c |6 +-- tools/perf/util/parse-events.l |3 +- tools/perf/util/parse-events.y |4 +- tools/perf/util/parse-options.c |2 +- tools/perf/util/perf_regs.h |2 +- tools/perf/util/pmu.y|6 +--
Re: A better idea
On 29/08/12 05:52, Franklin Teaburry wrote: > Wow, the internets have been flooded lately with brilliant suggestions along > the theme of dropping things. Clearly this is a sign that something need be > dropped! While I can certainly see a glimmer of wisdom among each of these > fine gentleman's suggestions I think they may still be a little off in their > estimation of what needs to go. > > Mr Furmann certainly took a step in the right direction when he began > pondering the operating system needs of a more mobile, device oriented > future. While the keyboard's days are certainly numbered though I'm not sure > that removing it needs to be the first link to remove from our chains of the > past. > > Instead.. let's focus on the positives... what a portable device needs rather > than what it doesn't. It needs to use power efficiently. It also needs to > shed it's heat easily as it is unlikely to have the fans and large inside > case space that our desktops once boasted. > > We need our software to run efficiently. The greeks knew how to do this... > they ran naked! I bet they shed heat pretty efficiently that way too! So... > While as we enter the new world, begining by dropping thing I suggest we > start with what the ancients already knew to drop. > > I suggest we all drop our pants!! > I just did and believe me it is liberating! > > Sincerely, > Mr. Franklin Teaburry > > > GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at > http://www.inbox.com/smileys > Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and > most webmails > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ By the gods, I think this might actually work! Next, TO ANTARCTICA! :D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] add discard support to nbd
nbd-trim-discard-support.diff Description: Binary data
[PATCH 1/2] add discard support to nbd
nbd-set-flags-ioctl.diff Description: Binary data
[PATCH 0/2] add discard support to nbd
This patchset adds discard request support to nbd. This should be good for inclusion in next. The first patch adds a set-flags ioctl, allowing various option flags to be set on an nbd device. One of the new flags tells the nbd client to send discard requests to the server. The second patch adds handling of discard requests to nbd when NBD_FLAG_SEND_TRIM is set. Thanks, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A better idea
Wow, the internets have been flooded lately with brilliant suggestions along the theme of dropping things. Clearly this is a sign that something need be dropped! While I can certainly see a glimmer of wisdom among each of these fine gentleman's suggestions I think they may still be a little off in their estimation of what needs to go. Mr Furmann certainly took a step in the right direction when he began pondering the operating system needs of a more mobile, device oriented future. While the keyboard's days are certainly numbered though I'm not sure that removing it needs to be the first link to remove from our chains of the past. Instead.. let's focus on the positives... what a portable device needs rather than what it doesn't. It needs to use power efficiently. It also needs to shed it's heat easily as it is unlikely to have the fans and large inside case space that our desktops once boasted. We need our software to run efficiently. The greeks knew how to do this... they ran naked! I bet they shed heat pretty efficiently that way too! So... While as we enter the new world, begining by dropping thing I suggest we start with what the ancients already knew to drop. I suggest we all drop our pants!! I just did and believe me it is liberating! Sincerely, Mr. Franklin Teaburry GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: use new exception_enter()/exception_exit() API in do_device_not_available()
x86: use new exception_enter()/exception_exit() API in
do_device_not_available()
RCU can be in extended quiescent state when do_device_not_available() called.
[ 676.400274] RCU used illegally from idle CPU!
[ 676.400274] rcu_scheduler_active = 1, debug_locks = 0
[ 676.400278] RCU used illegally from extended quiescent state!
[ 676.400282] 2 locks held by sed/9468:
[ 676.400285] #0: (>lock){-.-.-.}, at: []
__schedule+0x1c0/0x992
[ 676.400304] #1: (rcu_read_lock){.+.+..}, at: []
cpuacct_charge+0x27/0x1e0
[ 676.400321]
[ 676.400329] Call Trace:
[ 676.400340] [] lockdep_rcu_suspicious+0x109/0x112
[ 676.400347] [] cpuacct_charge+0x9e/0x1e0
[ 676.400353] [] ? cpuacct_charge+0x27/0x1e0
[ 676.400359] [] ? __schedule+0x1c0/0x992
[ 676.400366] [] update_curr+0x159/0x200
[ 676.400375] [] ? init_fpu+0x4e/0x8f
[ 676.400382] [] put_prev_task_fair+0x2a/0xac
[ 676.400388] [] __schedule+0x398/0x992
[ 676.400397] [] ? rcu_irq_exit+0x83/0x99
[ 676.400404] [] ? retint_restore_args+0x13/0x13
[ 676.400411] [] ? lock_is_held+0x2d/0xa5
[ 676.400414] [] ? init_fpu+0x4e/0x8f
[ 676.400417] [] __cond_resched+0x28/0x34
[ 676.400420] [] _cond_resched+0x2e/0x35
[ 676.400425] [] kmem_cache_alloc+0x4c/0x1c5
[ 676.400430] [] ? math_state_restore+0x1f/0xdc
[ 676.400433] [] init_fpu+0x4e/0x8f
[ 676.400437] [] math_state_restore+0x2e/0xdc
[ 676.400440] [] do_device_not_available+0xe/0x10
[ 676.400445] [] device_not_available+0x1b/0x20
Signed-off-by: Sergey Senozhatsky
---
arch/x86/kernel/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ab82cbd..dff3e72 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -654,7 +654,9 @@ do_device_not_available(struct pt_regs *regs, long
error_code)
return;
}
#endif
+ exception_enter(regs);
math_state_restore(); /* interrupts still off */
+ exception_enter(regs);
#ifdef CONFIG_X86_32
conditional_sti(regs);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: ozwpan: remove pointless conditional before kfree_skb()
On 28/08/2012 14:11, Wei Yongjun wrote:
From: Wei Yongjun
Remove pointless conditional before kfree_skb().
Signed-off-by: Wei Yongjun
---
drivers/staging/ozwpan/ozpd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/ozwpan/ozpd.c b/drivers/staging/ozwpan/ozpd.c
index 6c287ac..d515714 100644
--- a/drivers/staging/ozwpan/ozpd.c
+++ b/drivers/staging/ozwpan/ozpd.c
@@ -752,8 +752,7 @@ int oz_isoc_stream_create(struct oz_pd *pd, u8 ep_num)
*/
static void oz_isoc_stream_free(struct oz_isoc_stream *st)
{
- if (st->skb)
- kfree_skb(st->skb);
+ kfree_skb(st->skb);
kfree(st);
}
/*--
Acked-by: Rupesh Gujare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
Hello,
On Tue, Aug 28, 2012 at 10:37:36AM -0700, Kent Overstreet wrote:
> @@ -324,13 +342,37 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
> nr_iovecs, struct bio_set *bs)
> front_pad = 0;
> inline_vecs = nr_iovecs;
> } else {
> + /*
> + * generic_make_request() converts recursion to iteration; this
> + * means if we're running beneath it, any bios we allocate and
> + * submit will not be submitted (and thus freed) until after we
> + * return.
> + *
> + * This exposes us to a potential deadlock if we allocate
> + * multiple bios from the same bio_set() while running
> + * underneath generic_make_request(). If we were to allocate
> + * multiple bios (say a stacking block driver that was splitting
> + * bios), we would deadlock if we exhausted the mempool's
> + * reserve.
> + *
> + * We solve this, and guarantee forward progress, with a rescuer
> + * workqueue per bio_set. If we go to allocate and there are
> + * bios on current->bio_list, we first try the allocation
> + * without __GFP_WAIT; if that fails, we punt those bios we
> + * would be blocking to the rescuer workqueue before we retry
> + * with the original gfp_flags.
> + */
> +
> + if (current->bio_list && !bio_list_empty(current->bio_list))
> + gfp_mask &= ~__GFP_WAIT;
> +retry:
> p = mempool_alloc(bs->bio_pool, gfp_mask);
> front_pad = bs->front_pad;
> inline_vecs = BIO_INLINE_VECS;
> }
>
> if (unlikely(!p))
> - return NULL;
> + goto err;
>
> bio = p + front_pad;
> bio_init(bio);
> @@ -351,6 +393,19 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
> nr_iovecs, struct bio_set *bs)
>
> err_free:
> mempool_free(p, bs->bio_pool);
> +err:
> + if (gfp_mask != saved_gfp) {
> + gfp_mask = saved_gfp;
> +
> + spin_lock(>rescue_lock);
> + bio_list_merge(>rescue_list, current->bio_list);
> + bio_list_init(current->bio_list);
> + spin_unlock(>rescue_lock);
> +
> + queue_work(bs->rescue_workqueue, >rescue_work);
> + goto retry;
> + }
I wonder whether it would be easier to follow if this part is in-line
where retry: is. All that needs to be duplicated is single
mempool_alloc() call, right?
Overall, I *think* this is correct but need to think more about it to
be sure.
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: [GIT PULL] msm fixes for v3.6
Hi, On Tue, Aug 28, 2012 at 09:55:32AM -0700, David Brown wrote: > The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92: > > Linux 3.5 (2012-07-21 13:58:29 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git > tags/msm-fix-for3.6 > > for you to fetch changes up to e7501de53aa1a551526872f6c95901a00705f942: > > ARM: msm: Remove call to missing FPGA init on 8660 (2012-08-28 09:39:28 > -0700) > > > Fixes for two problems with MSM: > > - Mapping issue on 7x00 targets. > - Compilation problems with devicetree on 8660. Thanks for using a tag with a description of the pull request contents, but it seems like you're missing a bit here -- it has a patch for the dtbs target, and the handle_irq fix isn't technically breaking compilation, I believe? > > David Brown (1): > ARM: msm: Remove call to missing FPGA init on 8660 So, this seems to be breaking builds, seems appropriate as a fix. > Rohit Vaswani (2): > ARM: msm: io: Remove 7x30 iomap region from 7x00 > ARM: msm: io: Change the default static iomappings to be shared These two patches lack your Signed-off-by, even though you seem to have been the committer. Please add it. But also, it's not clear to me if the second of the two patches actually causes problems, or if it's just that the mapping won't be reused from the static range. If it's the latter, then I'd say it's 3.7 material instead. Also see my separate comment on the posted patch about the format of it. > Stephen Boyd (2): > ARM: msm: Add handle_irq handler for 8660 DT machine Clearly a bug fix, no problem. > ARM: msm: Add msm8660-surf.dts to Makefile.boot This one looks like 3.7 material. -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 v7 7/9] block: Add bio_clone_bioset(), bio_clone_kmalloc()
On Tue, Aug 28, 2012 at 10:37:34AM -0700, Kent Overstreet wrote:
> +static inline struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> +{
> + return bio_clone_bioset(bio, gfp_mask, fs_bio_set);
> +}
> +
...
> +static inline struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
> +{
> + return bio_clone_bioset(bio, gfp_mask, NULL);
> +
> +}
Do we really need these wrappers? I'd prefer requiring users to
explicit choose @bioset when cloning.
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/
