[GIT PULL FOR v3.9] Davinci VPSS Updates
Hi Mauro, Please pull the following patches for DaVinci VPSS driver. These patches have undergone under enormous reviews and are ready to be queued. Thanks and Regards, --Prabhakar Lad The following changes since commit 4bb891ebf60eb43ebd04e09bbcad24013067873f: [media] ivtv: ivtv-driver: Replace 'flush_work_sync()' (2012-12-20 15:22:30 -0200) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_mauro Manjunath Hadli (3): davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters drivers/media/platform/davinci/vpss.c | 70 - include/media/davinci/vpss.h | 16 +++ 2 files changed, 85 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] rtc: add new lp8788 rtc driver
TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight driver
and current sinks.
This patch enables LP8788 RTC module.
Patch v3.
remove __devinit and __devexit.
add weekday definition and comments.
Patch v2.
use IRQ domain for handling alarm IRQ.
replace module_init() and module_exit() with module_platform_driver().
clean up code for _probe() and _remove().
Patch v1.
initial patch
Signed-off-by: Milo(Woogyom) Kim
---
drivers/rtc/Kconfig |6 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-lp8788.c | 345 ++
3 files changed, 352 insertions(+)
create mode 100644 drivers/rtc/rtc-lp8788.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d0cea02..a3996c4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -194,6 +194,12 @@ config RTC_DRV_DS3232
This driver can also be built as a module. If so, the module
will be called rtc-ds3232.
+config RTC_DRV_LP8788
+ tristate "TI LP8788 RTC driver"
+ depends on MFD_LP8788
+ help
+ Say Y to enable support for the LP8788 RTC/ALARM driver.
+
config RTC_DRV_MAX6900
tristate "Maxim MAX6900"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c3f62c8..66050d8 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
obj-$(CONFIG_RTC_DRV_JZ4740) += rtc-jz4740.o
+obj-$(CONFIG_RTC_DRV_LP8788) += rtc-lp8788.o
obj-$(CONFIG_RTC_DRV_LPC32XX) += rtc-lpc32xx.o
obj-$(CONFIG_RTC_DRV_LOONGSON1)+= rtc-ls1x.o
obj-$(CONFIG_RTC_DRV_M41T80) += rtc-m41t80.o
diff --git a/drivers/rtc/rtc-lp8788.c b/drivers/rtc/rtc-lp8788.c
new file mode 100644
index 000..2363e52
--- /dev/null
+++ b/drivers/rtc/rtc-lp8788.c
@@ -0,0 +1,345 @@
+/*
+ * TI LP8788 MFD - rtc driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register address */
+#define LP8788_INTEN_3 0x05
+#define LP8788_RTC_UNLOCK 0x64
+#define LP8788_RTC_SEC 0x70
+#define LP8788_ALM1_SEC0x77
+#define LP8788_ALM1_EN 0x7D
+#define LP8788_ALM2_SEC0x7E
+#define LP8788_ALM2_EN 0x84
+
+/* mask/shift bits */
+#define LP8788_INT_RTC_ALM1_M BIT(1) /* Addr 05h */
+#define LP8788_INT_RTC_ALM1_S 1
+#define LP8788_INT_RTC_ALM2_M BIT(2) /* Addr 05h */
+#define LP8788_INT_RTC_ALM2_S 2
+#define LP8788_ALM_EN_MBIT(7) /* Addr 7Dh or 84h */
+#define LP8788_ALM_EN_S7
+
+#define DEFAULT_ALARM_SEL LP8788_ALARM_1
+#define LP8788_MONTH_OFFSET1
+#define LP8788_BASE_YEAR 2000
+#define MAX_WDAY_BITS 7
+#define LP8788_WDAY_SET1
+#define RTC_UNLOCK 0x1
+#define RTC_LATCH 0x2
+#define ALARM_IRQ_FLAG (RTC_IRQF | RTC_AF)
+
+enum lp8788_time {
+ LPTIME_SEC,
+ LPTIME_MIN,
+ LPTIME_HOUR,
+ LPTIME_MDAY,
+ LPTIME_MON,
+ LPTIME_YEAR,
+ LPTIME_WDAY,
+ LPTIME_MAX,
+};
+
+struct lp8788_rtc {
+ struct lp8788 *lp;
+ struct rtc_device *rdev;
+ enum lp8788_alarm_sel alarm;
+ int irq;
+};
+
+static const u8 addr_alarm_sec[LP8788_ALARM_MAX] = {
+ LP8788_ALM1_SEC,
+ LP8788_ALM2_SEC,
+};
+
+static const u8 addr_alarm_en[LP8788_ALARM_MAX] = {
+ LP8788_ALM1_EN,
+ LP8788_ALM2_EN,
+};
+
+static const u8 mask_alarm_en[LP8788_ALARM_MAX] = {
+ LP8788_INT_RTC_ALM1_M,
+ LP8788_INT_RTC_ALM2_M,
+};
+
+static const u8 shift_alarm_en[LP8788_ALARM_MAX] = {
+ LP8788_INT_RTC_ALM1_S,
+ LP8788_INT_RTC_ALM2_S,
+};
+
+static int _to_tm_wday(u8 lp8788_wday)
+{
+ int i;
+
+ if (lp8788_wday == 0)
+ return 0;
+
+ /* lookup defined weekday from read register value */
+ for (i = 0; i < MAX_WDAY_BITS; i++) {
+ if ((lp8788_wday >> i) == LP8788_WDAY_SET)
+ break;
+ }
+
+ return i + 1;
+}
+
+static inline int _to_lp8788_wday(int tm_wday)
+{
+ return LP8788_WDAY_SET << (tm_wday - 1);
+}
+
+static void lp8788_rtc_unlock(struct lp8788 *lp)
+{
+ lp8788_write_byte(lp, LP8788_RTC_UNLOCK, RTC_UNLOCK);
+ lp8788_write_byte(lp, LP8788_RTC_UNLOCK, RTC_LATCH);
+}
+
+static int lp8788_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct lp8788_rtc *rtc =
[PATCH v2 2/2] backlight: add new lp8788 backlight driver
TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight driver
and current sinks.
This patch enables LP8788 backlight module.
(Brightness mode)
The brightness is controlled by PWM input or I2C register.
All modes are supported in the driver.
(Platform data)
Configurable data can be defined in the platform side.
name : backlight driver name. (default: "lcd-backlight")
initial_brightness: initial value of backlight brightness
bl_mode : brightness control by PWM or lp8788 register
dim_mode : dimming mode selection
full_scale: full scale current setting
rise_time : brightness ramp up step time
fall_time : brightness ramp down step time
pwm_pol : PWM polarity setting when bl_mode is PWM based
period_ns : platform specific PWM period value. unit is nano.
The default values are set in case no platform data is defined.
Patch v2.
use generic PWM functions rather than lp8788 platform data function calls.
add configurable PWM period in the platform data.
replace module_init() and module_exit() with module_platform_driver().
Patch v1.
initial patch
Signed-off-by: Milo(Woogyom) Kim
---
drivers/video/backlight/Kconfig |6 +
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lp8788_bl.c | 350 +++
include/linux/mfd/lp8788.h | 16 +-
4 files changed, 360 insertions(+), 13 deletions(-)
create mode 100644 drivers/video/backlight/lp8788_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..455646a 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -369,6 +369,12 @@ config BACKLIGHT_LP855X
This supports TI LP8550, LP8551, LP8552, LP8553 and LP8556
backlight driver.
+config BACKLIGHT_LP8788
+ tristate "Backlight driver for TI LP8788 MFD"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788
+ help
+ This supports TI LP8788 backlight driver.
+
config BACKLIGHT_OT200
tristate "Backlight driver for ot200 visualisation device"
depends on BACKLIGHT_CLASS_DEVICE && CS5535_MFGPT && GPIO_CS5535
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..4d125ce 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_BACKLIGHT_LOCOMO)+= locomolcd.o
obj-$(CONFIG_BACKLIGHT_LM3630) += lm3630_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
+obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH) += cr_bllcd.o
diff --git a/drivers/video/backlight/lp8788_bl.c
b/drivers/video/backlight/lp8788_bl.c
new file mode 100644
index 000..fbf17bc
--- /dev/null
+++ b/drivers/video/backlight/lp8788_bl.c
@@ -0,0 +1,350 @@
+/*
+ * TI LP8788 MFD - backlight driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register address */
+#define LP8788_BL_CONFIG 0x96
+#define LP8788_BL_BRIGHTNESS 0x97
+#define LP8788_BL_RAMP 0x98
+
+/* mask/shift bits */
+#define LP8788_BL_EN BIT(0) /* Addr 96h */
+#define LP8788_BL_PWM_EN BIT(5)
+#define LP8788_BL_FULLSCALE_S 2
+#define LP8788_BL_DIM_MODE_S 1
+#define LP8788_BL_PWM_POLARITY_S 6
+#define LP8788_BL_RAMP_RISE_S 4 /* Addr 98h */
+
+#define BUF_SIZE 20
+#define MAX_BRIGHTNESS 127
+#define DEFAULT_BL_NAME"lcd-backlight"
+
+struct lp8788_bl_config {
+ enum lp8788_bl_ctrl_mode bl_mode;
+ enum lp8788_bl_dim_mode dim_mode;
+ enum lp8788_bl_full_scale_current full_scale;
+ enum lp8788_bl_ramp_step rise_time;
+ enum lp8788_bl_ramp_step fall_time;
+ enum lp8788_bl_pwm_polarity pwm_pol;
+};
+
+struct lp8788_bl {
+ struct lp8788 *lp;
+ struct backlight_device *bl_dev;
+ struct lp8788_backlight_platform_data *pdata;
+ enum lp8788_bl_ctrl_mode mode;
+ struct pwm_device *pwm;
+};
+
+struct lp8788_bl_config default_bl_config = {
+ .bl_mode= LP8788_BL_REGISTER_ONLY,
+ .dim_mode = LP8788_DIM_EXPONENTIAL,
+ .full_scale = LP8788_FULLSCALE_1900uA,
+ .rise_time = LP8788_RAMP_8192us,
+ .fall_time = LP8788_RAMP_8192us,
+ .pwm_pol= LP8788_PWM_ACTIVE_HIGH,
+};
+
+static inline bool
Re: [GIT PULL] user namespace and namespace infrastructure changes for 3.8
Rob Landley writes: > On 12/17/2012 05:18:57 PM, Eric W. Biederman wrote: >> Work remains to make it safe to build user namespaces and 9p, afs, >> ceph, cifs, coda, gfs2, ncpfs, nfs, nfsd, ocfs2, and xfs so the >> Kconfig >> guard remains in place preventing that user namespaces from being >> built >> when any of those filesystems are enabled. > > What work specifically? Essentially the uid_t to kuid_t and gid_t to kgid_t conversion. These are the more complex filesystems. And I haven't yet had the time to go through the preliminary patches in my development branch and convert them into stupid obviously correct patches, or review them closely. The changes generally are pretty simple the amount of review to ensure I didn't overlook things tends to proprotional to the size of the file system. There is also the fact that I don't use most of those file-systems. The big advantage of finishing those filesystems is that user namespaces can be turned on in allyesconfig, allowing my compile time checks to notice when someone doesn't use kuids and kgids. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] drivers: mailbox: framework creation
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson wrote: > While we can make the branch stable, would it make sense to make > remoteproc for omap depend on !multiplatform during the transition, to > reduce dependencies a little? Either way works, but it'd be nice to > keep them independent if we can. I'm not sure multiplatform is the culprit; OMAP's remoteproc driver heavily depends on this mailbox code, and obviously breaks with this patch-set if only for the the naming changes. We'll need this patch set to update omap's remoteproc as well so at least we don't break bisectibility, though running a sanity test before merging would be even nicer (Loic I can help if you don't have a panda board). BTW - grep shows that tidspbridge is using the mailbox code too, but it's in staging and I'm not sure it gets much love. Nevertheless, as long as it's there we should at least update it with the new API as well. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND] Ensure that kernel_init_freeable() is not inlined into non __init code
On Friday 21 December 2012 12:50 PM, Al Viro wrote: > On Fri, Dec 21, 2012 at 12:25:44PM +0530, Vineet Gupta wrote: >> Commit d6b2123802d "make sure that we always have a return path from >> kernel_execve()" reshuffled kernel_init()/init_post() to ensure that >> kernel_execve() has a caller to return to. >> >> It removed __init annotation for kernel_init() and introduced/calls a >> new routine kernel_init_freeable(). Latter however is inlined by any >> reasonable compiler (ARC gcc 4.4 in this case), causing slight code >> bloat. > Interesting... I assumed that explicitly set different section would be > enough, but I'd been wrong (or the original noinline would've been pointless, > now that I think of it). Consider it ACKed; I can pick it through signal.git, > and while it's not urgent I'd send it to Linus after -rc1, with Cc: stable. > Or you can send it to him yourself with my usual Acked-by - up to you. Merging via your signal.git is fine. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND] Ensure that kernel_init_freeable() is not inlined into non __init code
On Fri, Dec 21, 2012 at 12:25:44PM +0530, Vineet Gupta wrote: > Commit d6b2123802d "make sure that we always have a return path from > kernel_execve()" reshuffled kernel_init()/init_post() to ensure that > kernel_execve() has a caller to return to. > > It removed __init annotation for kernel_init() and introduced/calls a > new routine kernel_init_freeable(). Latter however is inlined by any > reasonable compiler (ARC gcc 4.4 in this case), causing slight code > bloat. Interesting... I assumed that explicitly set different section would be enough, but I'd been wrong (or the original noinline would've been pointless, now that I think of it). Consider it ACKed; I can pick it through signal.git, and while it's not urgent I'd send it to Linus after -rc1, with Cc: stable. Or you can send it to him yourself with my usual Acked-by - up to 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/
[PATCH] usb: tegra: Removing dependency on PHY instance number
Tegra2 has two varieties of USB PHYs:
Instance 0 - legacy PHY interface and
Instace 1 & 2 - non-legacy standard PHY interfaces.
PHY driver is using instance numbers to identify the
interface type.
With this patch Modified PHY driver to make use of
DT property for handling this.
ULPI PHY is used on USB PHY instance 1 & UTMI is
used on other two instances. Hence modified PHY type
detection also from instance number to the parameter
passed from host driver.
Signed-off-by: Venu Byravarasu
---
As PHY instance 2 is of UTMI type with non legacy interface,
replaced "phy->instance == 2" check in all UTMI functions
with "!phy->is_legacy_mode".
drivers/usb/host/ehci-tegra.c | 27 ++-
drivers/usb/phy/tegra_usb_phy.c | 66
include/linux/usb/tegra_usb_phy.h |8 +++--
3 files changed, 38 insertions(+), 63 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 55a9cde..9876700 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -615,7 +615,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
struct tegra_ehci_platform_data *pdata;
int err = 0;
int irq;
- int instance = pdev->id;
+ const struct device_node *np = pdev->dev.of_node;
+ bool is_legacy_mode;
pdata = pdev->dev.platform_data;
if (!pdata) {
@@ -685,29 +686,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- /* This is pretty ugly and needs to be fixed when we do only
-* device-tree probing. Old code relies on the platform_device
-* numbering that we lack for device-tree-instantiated devices.
-*/
- if (instance < 0) {
- switch (res->start) {
- case TEGRA_USB_BASE:
- instance = 0;
- break;
- case TEGRA_USB2_BASE:
- instance = 1;
- break;
- case TEGRA_USB3_BASE:
- instance = 2;
- break;
- default:
- err = -ENODEV;
- dev_err(>dev, "unknown usb instance\n");
- goto fail_io;
- }
- }
+ is_legacy_mode = of_property_read_bool(np, "nvidia,has-legacy-mode");
- tegra->phy = tegra_usb_phy_open(>dev, instance, hcd->regs,
+ tegra->phy = tegra_usb_phy_open(>dev, is_legacy_mode, hcd->regs,
pdata->phy_config,
TEGRA_USB_PHY_MODE_HOST);
if (IS_ERR(tegra->phy)) {
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
index 9d13c81..9385216 100644
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c
@@ -208,11 +208,6 @@ static struct tegra_utmip_config utmip_default[] = {
},
};
-static inline bool phy_is_ulpi(struct tegra_usb_phy *phy)
-{
- return (phy->instance == 1);
-}
-
static int utmip_pad_open(struct tegra_usb_phy *phy)
{
phy->pad_clk = clk_get_sys("utmip-pad", NULL);
@@ -221,7 +216,7 @@ static int utmip_pad_open(struct tegra_usb_phy *phy)
return PTR_ERR(phy->pad_clk);
}
- if (phy->instance == 0) {
+ if (phy->is_legacy_mode) {
phy->pad_regs = phy->regs;
} else {
phy->pad_regs = ioremap(TEGRA_USB_BASE, TEGRA_USB_SIZE);
@@ -236,7 +231,7 @@ static int utmip_pad_open(struct tegra_usb_phy *phy)
static void utmip_pad_close(struct tegra_usb_phy *phy)
{
- if (phy->instance != 0)
+ if (!phy->is_legacy_mode)
iounmap(phy->pad_regs);
clk_put(phy->pad_clk);
}
@@ -305,7 +300,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
unsigned long val;
void __iomem *base = phy->regs;
- if (phy->instance == 0) {
+ if (phy->is_legacy_mode) {
val = readl(base + USB_SUSP_CTRL);
val |= USB_SUSP_SET;
writel(val, base + USB_SUSP_CTRL);
@@ -315,9 +310,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
val = readl(base + USB_SUSP_CTRL);
val &= ~USB_SUSP_SET;
writel(val, base + USB_SUSP_CTRL);
- }
-
- if (phy->instance == 2) {
+ } else {
val = readl(base + USB_PORTSC1);
val |= USB_PORTSC1_PHCD;
writel(val, base + USB_PORTSC1);
@@ -332,7 +325,7 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
unsigned long val;
void __iomem *base = phy->regs;
- if (phy->instance == 0) {
+ if (phy->is_legacy_mode) {
val = readl(base + USB_SUSP_CTRL);
val |= USB_SUSP_CLR;
writel(val, base + USB_SUSP_CTRL);
@@ -342,9 +335,7 @@ static void
Re: CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)
On Fri, Dec 21, 2012 at 11:54:08AM +0530, Vineet Gupta wrote: > On Friday 21 December 2012 05:51 AM, Al Viro wrote: > > sigaltstack infrastructure + conversion for x86, alpha and um, > > COMPAT_SYSCALL_DEFINE infrastructure. Note that there are several > > conflicts between "unify SS_ONSTACK/SS_DISABLE definitions" and > > UAPI patches in mainline; resolution is trivial - just remove definitions > > of SS_ONSTACK and SS_DISABLED from arch/*/uapi/asm/signal.h; they are > > all identical and include/uapi/linux/signal.h contains the unified > > variant. Please, pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus > > > > Hi Arnd, > > In Linus' tree with above merged, selecting CONFIG_GENERIC_SIGALTSTACK > is causing build issues for ARC port (and possibly others as well) which > use asm-generic/syscalls.h due to a different prototype for > sys_sigaltstack coming in from linux/syscalls.h > > While I can band-aid ARC port by #define sys_sigaltstack before > including asm-generic, it might be better if we conditional-ize one of > the prototypes. Following works for me. TBH, the plan was to use such band-aids until all ports using asm-generic/syscalls.h switch to generic and we drop the damn prototype from there. But yes, what you are suggesting would also do. As for asm-generic/syscalls.h, it should simply die out. Look: sys_sigaltstack() eventually goes to linux/syscalls.h, where it ought to be anyway. sys_rt_sigreturn() should be there as well - and it should be long (void); current_pt_regs() is there for purpose... sys_rt_sigsuspend() and and should go into linux/syscalls.h too - the only obstacle is mips and it can simply drop its private implementation and use the generic one. Et cetera... I hope to kill it completely in the next cycle, along with quite a few things in arch/*/include/asm/syscalls.h. FWIW, the plan for this cycle signal.git is to put a bunch of generic variants of syscalls into kernel/signal.c (we have a lot of pointless code duplication, mostly in compat ones) and start a bunch of no-rebase arch-$ARCH branches at that point, as it had been done for kernel_thread series - i.e. safely mergable into architecture git trees and going to Linus either that way or through signal.git, preferably the former. sigaltstack(2) definitely should get unified by the end of that, and I hope to get several kilolines of code killed in compat stuff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] user namespace and namespace infrastructure changes for 3.8
On 12/17/2012 05:18:57 PM, Eric W. Biederman wrote: Work remains to make it safe to build user namespaces and 9p, afs, ceph, cifs, coda, gfs2, ncpfs, nfs, nfsd, ocfs2, and xfs so the Kconfig guard remains in place preventing that user namespaces from being built when any of those filesystems are enabled. What work specifically? Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Ensure that kernel_init_freeable() is not inlined into non __init code
Commit d6b2123802d "make sure that we always have a return path from
kernel_execve()" reshuffled kernel_init()/init_post() to ensure that
kernel_execve() has a caller to return to.
It removed __init annotation for kernel_init() and introduced/calls a
new routine kernel_init_freeable(). Latter however is inlined by any
reasonable compiler (ARC gcc 4.4 in this case), causing slight code
bloat.
This patch forces kernel_init_freeable() as noinline reducing the .text
bloat-o-meter vmlinux vmlinux_new
add/remove: 1/0 grow/shrink: 0/1 up/down: 374/-334 (40)
functionold new delta
kernel_init_freeable - 374+374 (.init.text)
kernel_init 628 294-334 (.text)
Just for documentation, here's what Al's orig commit did.
Orig
THREAD __init kernel_init()
smp_init()
...
open("/dev/console")
init_post() --> forced to be noinline
return 0;
init_post()
free_initmem() --> reaps caller kernel_init()
run_init_process("/init")
kernel_execve
New
---
THREAD kernel_init()
kernel_init_freeable() --> __init tagged
smp_init()
...
open("/dev/console")
free_initmem() --> reaps kernel_init_freeable()
run_init_process "init"
kernel_execve
Signed-off-by: Vineet Gupta
CC: Rusty Russell
CC: Jim Cromie
CC: Andrew Morton
CC: "H. Peter Anvin"
CC: linux-kernel@vger.kernel.org
---
init/main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/main.c b/init/main.c
index 85d69df..92d728a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -802,7 +802,7 @@ static int run_init_process(const char *init_filename)
(const char __user *const __user *)envp_init);
}
-static void __init kernel_init_freeable(void);
+static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
{
@@ -845,7 +845,7 @@ static int __ref kernel_init(void *unused)
"See Linux Documentation/init.txt for guidance.");
}
-static void __init kernel_init_freeable(void)
+static noinline void __init kernel_init_freeable(void)
{
/*
* Wait until kthreadd is all set-up.
--
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 v3] usb: phy: use kzalloc to allocate struct tegra_usb_phy
Use kzalloc instead of kmalloc to allocate struct tegra_usb_phy. This ensures that all function pointers in member u_phy are initialized to NULL. Signed-off-by: Venu Byravarasu --- This patch is v3 patch for the patch discussed at http://marc.info/?l=linux-kernel=135599303216132=2 drivers/usb/phy/tegra_usb_phy.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c index 04bf5d2..dedead5 100644 --- a/drivers/usb/phy/tegra_usb_phy.c +++ b/drivers/usb/phy/tegra_usb_phy.c @@ -736,7 +736,7 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int err; u8 index = is_legacy_mode ? 0 : 2; - phy = kmalloc(sizeof(struct tegra_usb_phy), GFP_KERNEL); + phy = kzalloc(sizeof(struct tegra_usb_phy), GFP_KERNEL); if (!phy) return ERR_PTR(-ENOMEM); -- 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/
Re: [PATCH] sched/rt: Move cpu rq properties from "struct rt_rq" to "struct rq"
21.12.2012, 03:07, "Steven Rostedt" :
> On Fri, 2012-12-21 at 02:16 +0400, Kirill Tkhai wrote:
>
>> 20.12.2012, 21:53, "Thomas Gleixner" :
>>> On Tue, 18 Dec 2012, Kirill Tkhai wrote:
The members rt_nr_total, rt_nr_migratory, overloaded and pushable_tasks
are
properties of cpu runqueue, not group rt_rq.
>>> Why?
>> Because, they depend on number and properties of all processes of rq, not
>> of nested rt_rq.
>
> You're answer is still confusing.
>
> struct rq {
> [...]
> struct rt_rq rt;
>
> rt_rq is just a part of rq. What's the point?
>
> rq = container_of(rt_rq, struct rt_rq, rt);
>
> As the comment above struct rt_rq says:
>
> /* Real-Time classes' related field in a runqueue: */
>
> Those look like fields related to the Real-Time class. I don't see them
> used outside of kernel/sched/rt.c
>
entity_1->my_q_1
/
/
rq->rt -entity_2->my_q_2
\
\
entity_n->my_q_n
I say about child rt_rqs (my_q_1my_q_n). They don't have rt_nr_total,
rt_nr_migratory, overloaded and pushable_tasks.
The only use of overloaded, for example, is "rq->rt.overloaded". The same with
other variables.
Kirill
> -- Steve
>
>>> Thanks,
>>>
>>> tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] stack and heap are executable on x86_64
On Thu, Dec 20, 2012 at 8:44 PM, H. Peter Anvin wrote: > I just looked at a /sys/kernel/debug/kernel_page_tables dump and there > are a bunch of pages which are RWX: > > 0x8800-0x88097000 604K RW GLB x pte > 0x8809d000-0x8820 1420K RW GLB x pte > 0x8820-0x88000100 14M RW PSE GLB x pmd > 0x880001c0-0x880035e0 834M RW PSE GLB x pmd > 0x880035e0-0x880035ffe000 2040K RW GLB x pte > 0x880036ff7000-0x88003700 36K RW GLB x pte > 0x88003700-0x88004000 144M RW PSE GLB x pmd > 0x81c0-0x81cea000 936K RW GLB x pte > 0x81dfd000-0x81e0 12K RW GLB x pte > 0x81e0-0x82002M RW PSE GLB x pmd after for-x86-boot we will have ---[ Low Kernel Mapping ]--- 0x8800-0x88099000 612K RW GLB NX pte 0x88099000-0x8809a000 4K ro GLB NX pte 0x8809a000-0x8809b000 4K ro GLB x pte 0x8809b000-0x88201428K RW GLB NX pte 0x8820-0x8800dfe03580M RW PSE GLB NX pmd 0x8800dfe0-0x8800dfffe0002040K RW GLB NX pte 0x8800dfffe000-0x8800e000 8K pte 0x8800e000-0x8801 512M pmd 0x8801-0x8801a0002560M RW PSE GLB NX pmd ---[ High Kernel Mapping ]--- 0x8000-0x8100 16M pmd 0x8100-0x82a0 26M RW PSE GLB x pmd 0x82a0-0x82b210001156K RW GLB x pte 0x82b21000-0x82c0 892K RW GLB NX pte 0x82c0-0x82e0 2M RW PSE GLB NX pmd 0x82e0-0x82e92000 584K RW GLB NX pte 0x82e92000-0x83001464K RW GLB x pte 0x8300-0x83c0 12M RW PSE GLB x pmd 0x83c0-0xa000 452M pmd so low mapping will only have trampoline get x set. is that expected ? Do we need to set low mapping corresponding to kernel range to x? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 21.12.2012 00:28, Stephen Warren wrote: > On 12/20/2012 02:34 PM, Terje Bergström wrote: >> On 20.12.2012 22:30, Thierry Reding wrote: >>> The problem with your proposed solution is that, even any of Stephen's >>> valid objections aside, it won't work. Once the tegra-drm module is >>> unloaded, the driver's data will be left in the current state and the >>> link to the dummy device will be lost. >> >> The dummy device is created by tegradrm's module init, because it's used > > No, the tegradrm driver object might be registered by tegradrm's module > init, but the dummy tegradrm platform device would need to be > created/registered by host1x's probe. Otherwise, the device would get > created even if there was no host1x/... in the system (disabled for some > reason, multi-SoC kernel, ...) Oh. I was all the time thinking that dummy device needs to be created by tegradrm, because it's only used by tegradrm. But as we're mixing the responsibilities, we might then just as well go all the way. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)
On Friday 21 December 2012 05:51 AM, Al Viro wrote: > sigaltstack infrastructure + conversion for x86, alpha and um, > COMPAT_SYSCALL_DEFINE infrastructure. Note that there are several > conflicts between "unify SS_ONSTACK/SS_DISABLE definitions" and > UAPI patches in mainline; resolution is trivial - just remove definitions > of SS_ONSTACK and SS_DISABLED from arch/*/uapi/asm/signal.h; they are > all identical and include/uapi/linux/signal.h contains the unified > variant. Please, pull from > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus > Hi Arnd, In Linus' tree with above merged, selecting CONFIG_GENERIC_SIGALTSTACK is causing build issues for ARC port (and possibly others as well) which use asm-generic/syscalls.h due to a different prototype for sys_sigaltstack coming in from linux/syscalls.h While I can band-aid ARC port by #define sys_sigaltstack before including asm-generic, it might be better if we conditional-ize one of the prototypes. Following works for me. diff --git a/include/asm-generic/syscalls.h b/include/asm-generic/syscalls.h index 58f466f..1db51b8 100644 --- a/include/asm-generic/syscalls.h +++ b/include/asm-generic/syscalls.h @@ -21,10 +21,12 @@ asmlinkage long sys_mmap(unsigned long addr, unsigned long len, unsigned long fd, off_t pgoff); #endif +#ifndef CONFIG_GENERIC_SIGALTSTACK #ifndef sys_sigaltstack asmlinkage long sys_sigaltstack(const stack_t __user *, stack_t __user *, struct pt_regs *); #endif +#endif #ifndef sys_rt_sigreturn asmlinkage long sys_rt_sigreturn(struct pt_regs *regs); Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 09/11] x86/head64.c: Early update ucode in 64-bit
Careful... accessing global varibles is tricky on the 32-bit side. Yinghai Lu wrote: >Yeah, even better! > >32 bit has bootparms copied too > > >On Thursday, December 20, 2012, Yu, Fenghua wrote: > >> > > From: yhlu.ker...@gmail.com [mailto: >> yhlu.ker...@gmail.com ] On Behalf >> > Of >> > > Yinghai Lu >> > > On Thu, Dec 20, 2012 at 11:48 AM, Fenghua Yu > >> > >> > > wrote: >> > > > From: Fenghua Yu > >> > > > >> > > > This updates ucode on BSP in 64-bit mode. Paging and virtual >> > address >> > > are >> > > > working now. >> > > > >> > > > Signed-off-by: Fenghua Yu > >> > > > --- >> > > > arch/x86/kernel/head64.c | 6 ++ >> > > > 1 file changed, 6 insertions(+) >> > > > >> > > > diff --git a/arch/x86/kernel/head64.c >b/arch/x86/kernel/head64.c >> > > > index e1cb611..1ccbaf1 100644 >> > > > --- a/arch/x86/kernel/head64.c >> > > > +++ b/arch/x86/kernel/head64.c >> > > > @@ -26,6 +26,7 @@ >> > > > #include >> > > > #include >> > > > #include >> > > > +#include >> > > > >> > > > /* >> > > > * Manage page tables very early on. >> > > > @@ -179,6 +180,11 @@ void __init x86_64_start_kernel(char * >> > > real_mode_data) >> > > > } >> > > > load_idt((const struct desc_ptr *)_descr); >> > > > >> > > > + /* >> > > > +* Load microcode early on BSP. >> > > > +*/ >> > > > + load_ucode_bsp(__va(real_mode_data)); >> > > > + >> > > > copy_bootdata(__va(real_mode_data)); >> > > >> > > can you make load_ucode_bsp take boot_param directly instead of >> > > real_mode_data. ? >> > > >> > > could be >> > > >> > > >> > > copy_bootdata(__va(real_mode_data)); >> > > + >> > > +/* Load microcode early on BSP. */ >> > > + load_ucode_bsp(_params); >> > > + >> > > >> > > because copy_bootdata, already copy boot_params... >> > > >> > > Thanks >> > > >> > > Yinghai >> > >> > That's right. Will fix this. >> >> I'll call load_ucode_bsp(void) though which will access the global >> boot_params variable. >> >> Thanks. >> >> -Fenghua >> -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new architectures, time_t __kernel_long_t
Fair enough. Al Viro wrote: >On Thu, Dec 20, 2012 at 09:05:30PM -0800, H. Peter Anvin wrote: >> >... as long as we do not have typedef __kernel_foo_t foo_t in >linux/types.h. >> > >> >> In the case of things like nlink_t and dev_t I would suggest we >> explicitly call out the types as kernel and user. I would suggest >> knlink_t and unlink_t but the latter made me want to stab my eyes >> out due to its confusion potential, so I wonder if we should >> establish a new convention with _kt (kernel type) and _ut (user >> type) suffixes, so nlink_kt and nlink_ut, alternatively one could >> consider k_nlink_t and u_nlink_t. > >What the hell for? _Which_ userland nlink_t, anyway? We have quite a >few >struct stat variants in there. Sorry, but I really don't see any point >in that, and a lot of potential for confusion. Marshalling is about >the >only thing we need the userland ones for and the code doing it is just >fine >with the only object of that type in sight being the field of e.g. >struct stat >with given name... -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 3/6] sched: pack small tasks
Hi Vincent,
On Thu, Dec 13, 2012 at 11:11:11AM +0100, Vincent Guittot wrote:
> On 13 December 2012 03:17, Alex Shi wrote:
> > On 12/12/2012 09:31 PM, Vincent Guittot wrote:
> >> +static bool is_buddy_busy(int cpu)
> >> +{
> >> + struct rq *rq = cpu_rq(cpu);
> >> +
> >> + /*
> >> + * A busy buddy is a CPU with a high load or a small load with a lot
> >> of
> >> + * running tasks.
> >> + */
> >> + return ((rq->avg.runnable_avg_sum << rq->nr_running) >
> >
> > If nr_running a bit big, rq->avg.runnable_avg_sum << rq->nr_running is
> > zero. you will get the wrong decision.
>
> yes, I'm going to do that like below instead:
> return (rq->avg.runnable_avg_sum > (rq->avg.runnable_avg_period >>
> rq->nr_running));
Doesn't it consider nr_running too much? It seems current is_buddy_busy
returns false on a cpu that has 1 task runs 40% cputime, but returns true
on a cpu that has 3 tasks runs 10% cputime each or for 2 tasks of 15%
cputime each, right?
I don't know what is correct, but just guessing that in a cpu's point
of view it'd be busier if it has a higher runnable_avg_sum than a
higher nr_running IMHO.
>
> >
> >> + rq->avg.runnable_avg_period);
> >> +}
> >> +
> >> +static bool is_light_task(struct task_struct *p)
> >> +{
> >> + /* A light task runs less than 25% in average */
> >> + return ((p->se.avg.runnable_avg_sum << 1) <
> >> + p->se.avg.runnable_avg_period);
> >
> > 25% may not suitable for big machine.
>
> Threshold is always an issue, which threshold should be suitable for
> big machine ?
>
> I'm wondering if i should use the imbalance_pct value for computing
> the threshold
Anyway, I wonder how 'sum << 1' computes 25%. Shouldn't it be << 2 ?
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.8 NFS build breakage with !CONFIG_NFS_FSCACHE
Hi David,
Not sure if this was report/fixed already - but as of today's Linus tree
(tip has commit 96680d2), I'm seeing a build breakage due to a trivial
missing def for nfs_fscache_wait_on_invalidate.
Following fixes it for me.
diff --git a/fs/nfs/fscache.h b/fs/nfs/fscache.h
index 277b027..4ecb766 100644
--- a/fs/nfs/fscache.h
+++ b/fs/nfs/fscache.h
@@ -222,6 +222,7 @@ static inline void nfs_readpage_to_fscache(struct
inode *inode,
static inline void nfs_fscache_invalidate(struct inode *inode) {}
+static inline void nfs_fscache_wait_on_invalidate(struct inode *inode) {}
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] mm: Update file times when inodes are written after mmaped writes
On Thu, Dec 20, 2012 at 4:34 PM, Jan Kara wrote:
> On Thu 20-12-12 15:10:10, Andy Lutomirski wrote:
>> The onus is currently on filesystems to call file_update_time
>> somewhere in the page_mkwrite path. This is unfortunate for three
>> reasons:
>>
>> 1. page_mkwrite on a locked page should be fast. ext4, for example,
>>often sleeps while dirtying inodes.
>>
>> 2. The current behavior is surprising -- the timestamp resulting from
>>an mmaped write will be before the write, not after. This contradicts
>>the mmap(2) manpage, which says:
>>
>> The st_ctime and st_mtime field for a file mapped with PROT_WRITE and
>> MAP_SHARED will be updated after a write to the mapped region, and
>> before a subsequent msync(2) with the MS_SYNC or MS_ASYNC flag, if one
>> occurs.
> I agree your behavior is more correct wrt to the manpage / spec. OTOH I
> could dig out several emails where users complain time stamps magically
> change some time after the file was written via mmap (because writeback
> happened at that time and it did some allocation to the inode). People hit
> this e.g. when compiling something, ld(1) writes final binary through mmap,
> the package / archive the final binary and later some sanity check finds
> the time stamp on the binary is newer than the package / archive.
>
> Looking more into the patch you end up updating timestamps on munmap(2)
> (thus on file close in particular). That should avoid the most surprising
> cases and users hopefully won't notice the difference. Good. But please
> mention this explicitely in the changelog.
I was careful to get that case right. I'll update the changelog.
In particular, I've so far tested munmap, msync(MS_SYNC), fsync,
waiting 30 seconds, and dying by fatal signal. All of those paths
work right.
>> +/**
>> + * inode_update_time_writable - update mtime and ctime time
>> + * @inode: inode accessed
>> + *
>> + * This is like file_update_time, but it assumes the mnt is writable
>> + * and takes an inode parameter instead.
>> + */
>> +
>> +int inode_update_time_writable(struct inode *inode)
>> +{
>> + struct timespec now;
>> + int sync_it = 0;
>> + int ret;
>> +
>> + /* First try to exhaust all avenues to not sync */
>> + if (IS_NOCMTIME(inode))
>> + return 0;
>> +
>> + now = current_fs_time(inode->i_sb);
>> + if (!timespec_equal(>i_mtime, ))
>> + sync_it = S_MTIME;
>> +
>> + if (!timespec_equal(>i_ctime, ))
>> + sync_it |= S_CTIME;
>> +
>> + if (IS_I_VERSION(inode))
>> + sync_it |= S_VERSION;
>> +
>> + if (!sync_it)
>> + return 0;
>> +
>> + ret = update_time(inode, , sync_it);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(inode_update_time_writable);
>> +
> So this differs from file_update_time() only by not calling
> __mnt_want_write(). Why this special function? It is actually unsafe wrt
> remounts read-only or filesystem freezing... For that you need to call
> sb_start_write() / sb_end_write() around the timestamp update. Umm, or
> better sb_start_pagefault() / sb_end_pagefault() because the call in
> remove_vma() gets called under mmap_sem so we are in a rather similar
> situation to ->page_mkwrite.
The important difference is that it takes an inode* as a parameter
instead of a file*. I don't think that inodes have a struct vfsmount,
so I can't call __mnt_want_write. I'll take a look at
sb_start_pagefault. I'll also refactor this a bit to minimize code
duplication. The current approach was for the v1 rfc version. :)
>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 3913262..60301dc 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -223,6 +223,10 @@ static struct vm_area_struct *remove_vma(struct
>> vm_area_struct *vma)
>> struct vm_area_struct *next = vma->vm_next;
>>
>> might_sleep();
>> +
>> + if (vma->vm_file)
>> + mapping_flush_cmtime(vma->vm_file->f_mapping);
>> +
>> if (vma->vm_ops && vma->vm_ops->close)
>> vma->vm_ops->close(vma);
>> if (vma->vm_file)
>> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
>> index cdea11a..8cbb7fb 100644
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -1910,6 +1910,13 @@ int do_writepages(struct address_space *mapping,
>> struct writeback_control *wbc)
>> ret = mapping->a_ops->writepages(mapping, wbc);
>> else
>> ret = generic_writepages(mapping, wbc);
>> +
>> + /*
>> + * This is after writepages because the AS_CMTIME bit won't
>> + * bet set until writepages is called.
>> + */
>> + mapping_flush_cmtime(mapping);
>> +
>> return ret;
>> }
>>
>> @@ -2117,8 +2124,17 @@ EXPORT_SYMBOL(set_page_dirty);
>> */
>> int set_page_dirty_from_pte(struct page *page)
>> {
>> - /* Doesn't do anything interesting yet. */
>> - return set_page_dirty(page);
>> + int ret = set_page_dirty(page);
>> +
>> +
Re: [RFC PATCH 2/4] mm: Update file times when inodes are written after mmaped writes
On Thu, Dec 20, 2012 at 4:14 PM, Dave Chinner wrote: > On Thu, Dec 20, 2012 at 03:10:10PM -0800, Andy Lutomirski wrote: >> The onus is currently on filesystems to call file_update_time >> somewhere in the page_mkwrite path. This is unfortunate for three >> reasons: >> >> 1. page_mkwrite on a locked page should be fast. ext4, for example, >>often sleeps while dirtying inodes. > > That's an ext4 problem, not a page fault or timestamp update > problem. Fix ext4. I could fix ext4 (or rather, someone who understands jbd2 could fix ext4), but I think my approach is considerably simpler and fixes all filesystems at once. > >> 2. The current behavior is surprising -- the timestamp resulting from >>an mmaped write will be before the write, not after. This contradicts >>the mmap(2) manpage, which says: >> >> The st_ctime and st_mtime field for a file mapped with PROT_WRITE and >> MAP_SHARED will be updated after a write to the mapped region, and >> before a subsequent msync(2) with the MS_SYNC or MS_ASYNC flag, if one >> occurs. > > What you propose (time updates in do_writepages()) violates this. > msync(MS_ASYNC) doesn't actually start any IO, therefore the > timestamp wil not be updated. That's easy enough -- I can add special-case code for MS_ASYNC. It'll make an operation that is otherwise a no-op considerably less free, though. > > Besides, what POSIX actually says is: [snipped -- covered elsewhere in the thread] > >> 3. (An ulterior motive) I'd like to use hardware dirty tracking for >>shared, locked, writable mappings (instead of page faults). Moving >>important work out of the page_mkwrite path is an important first step. > > I don't think you're going to get very far doing this. page_mkwrite > needs to do: > > a) block allocation in page_mkwrite() for faults over holes >to detect ENOSPC conditions immediately rather than in >writeback when such an error results in data loss. > b) detect writes over unwritten extents so that the pages in >the page cache can be set up correctly for conversion to >occur during writeback. > > Correcting these two problems was the reason for introducing > page_mkwrite in the first place - we need to do this stuff before > the page fault is completed, and that means, by definition, > page_mkwrite needs to be able to block. Moving c/mtime updates out > of the way does not, in any way, change these requirements. I was unclear. I have no problem if PROT_WRITE, MAP_SHARED pages start out write protected. I want two changes from the status quo, though: 1. ptes (maybe only if mlocked or maybe even only if some new madvise flag is set) should be marked clean but stay writable during and after writeback. (This would only work when stable pages are not in effect.) 2. There should be a way to request that pages be made clean-but-writable. #1 should be mostly fine already from the filesystems' point of view. #2 would involve calling page_mkwrite or some equivalent. I suspect that there are bugs that are currently untriggerable involving clean-but-writable pages. For example, what happens if cpu 0 (atomically) changes a pte from clean/writable to not present, but cpu 1 writes the page before the TLB flush happens. I think the pte ends up not present + dirty, but the current unmapping code won't notice. This would involve splitting page_mkclean into "make clean and write protect" and "make clean but leave writable". Doing this would avoid ~1M "soft" page faults per day in a single real-time thread in my software. (The file time patches are to make sure that the "soft" page faults actually don't sleep.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] backlight: corgi_lcd: use lcd_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
lcd_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct lcd_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/corgi_lcd.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index 13ef511..aa782f3 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -337,7 +337,7 @@ static void corgi_lcd_power_off(struct corgi_lcd *lcd)
static int corgi_lcd_set_mode(struct lcd_device *ld, struct fb_videomode *m)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = lcd_get_data(ld);
int mode = CORGI_LCD_MODE_QVGA;
if (m->xres == 640 || m->xres == 480)
@@ -364,7 +364,7 @@ static int corgi_lcd_set_mode(struct lcd_device *ld, struct
fb_videomode *m)
static int corgi_lcd_set_power(struct lcd_device *ld, int power)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = lcd_get_data(ld);
if (POWER_IS_ON(power) && !POWER_IS_ON(lcd->power))
corgi_lcd_power_on(lcd);
@@ -378,7 +378,7 @@ static int corgi_lcd_set_power(struct lcd_device *ld, int
power)
static int corgi_lcd_get_power(struct lcd_device *ld)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = lcd_get_data(ld);
return lcd->power;
}
--
1.7.2.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 6/6] backlight: omap1: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/omap1_bl.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index af31c26..6271101 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -77,7 +77,7 @@ static void omapbl_blank(struct omap_backlight *bl, int mode)
static int omapbl_suspend(struct platform_device *pdev, pm_message_t state)
{
struct backlight_device *dev = platform_get_drvdata(pdev);
- struct omap_backlight *bl = dev_get_drvdata(>dev);
+ struct omap_backlight *bl = bl_get_data(dev);
omapbl_blank(bl, FB_BLANK_POWERDOWN);
return 0;
@@ -86,7 +86,7 @@ static int omapbl_suspend(struct platform_device *pdev,
pm_message_t state)
static int omapbl_resume(struct platform_device *pdev)
{
struct backlight_device *dev = platform_get_drvdata(pdev);
- struct omap_backlight *bl = dev_get_drvdata(>dev);
+ struct omap_backlight *bl = bl_get_data(dev);
omapbl_blank(bl, bl->powermode);
return 0;
@@ -98,7 +98,7 @@ static int omapbl_resume(struct platform_device *pdev)
static int omapbl_set_power(struct backlight_device *dev, int state)
{
- struct omap_backlight *bl = dev_get_drvdata(>dev);
+ struct omap_backlight *bl = bl_get_data(dev);
omapbl_blank(bl, state);
bl->powermode = state;
@@ -108,7 +108,7 @@ static int omapbl_set_power(struct backlight_device *dev,
int state)
static int omapbl_update_status(struct backlight_device *dev)
{
- struct omap_backlight *bl = dev_get_drvdata(>dev);
+ struct omap_backlight *bl = bl_get_data(dev);
if (bl->current_intensity != dev->props.brightness) {
if (bl->powermode == FB_BLANK_UNBLANK)
@@ -124,7 +124,7 @@ static int omapbl_update_status(struct backlight_device
*dev)
static int omapbl_get_intensity(struct backlight_device *dev)
{
- struct omap_backlight *bl = dev_get_drvdata(>dev);
+ struct omap_backlight *bl = bl_get_data(dev);
return bl->current_intensity;
}
--
1.7.2.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 5/6] backlight: tosa: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/tosa_bl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index 588682c..2326fa8 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -54,7 +54,7 @@ static void tosa_bl_set_backlight(struct tosa_bl_data *data,
int brightness)
static int tosa_bl_update_status(struct backlight_device *dev)
{
struct backlight_properties *props = >props;
- struct tosa_bl_data *data = dev_get_drvdata(>dev);
+ struct tosa_bl_data *data = bl_get_data(dev);
int power = max(props->power, props->fb_blank);
int brightness = props->brightness;
--
1.7.2.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 4/6] backlight: corgi_lcd: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/corgi_lcd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index 77c81f8..13ef511 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -391,7 +391,7 @@ static struct lcd_ops corgi_lcd_ops = {
static int corgi_bl_get_intensity(struct backlight_device *bd)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = bl_get_data(bd);
return lcd->intensity;
}
@@ -423,7 +423,7 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd,
int intensity)
static int corgi_bl_update_status(struct backlight_device *bd)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = bl_get_data(bd);
int intensity = bd->props.brightness;
if (bd->props.power != FB_BLANK_UNBLANK)
--
1.7.2.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 3/6] backlight: ams369fg06: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/ams369fg06.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/ams369fg06.c
b/drivers/video/backlight/ams369fg06.c
index bd8a320..d29e494 100644
--- a/drivers/video/backlight/ams369fg06.c
+++ b/drivers/video/backlight/ams369fg06.c
@@ -421,7 +421,7 @@ static int ams369fg06_set_brightness(struct
backlight_device *bd)
{
int ret = 0;
int brightness = bd->props.brightness;
- struct ams369fg06 *lcd = dev_get_drvdata(>dev);
+ struct ams369fg06 *lcd = bl_get_data(bd);
if (brightness < MIN_BRIGHTNESS ||
brightness > bd->props.max_brightness) {
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] pwm_backlight: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
Cc: Thierry Reding
---
drivers/video/backlight/pwm_bl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 069983c..f2f4c43 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -37,7 +37,7 @@ struct pwm_bl_data {
static int pwm_backlight_update_status(struct backlight_device *bl)
{
- struct pwm_bl_data *pb = dev_get_drvdata(>dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
int brightness = bl->props.brightness;
int max = bl->props.max_brightness;
@@ -83,7 +83,7 @@ static int pwm_backlight_get_brightness(struct
backlight_device *bl)
static int pwm_backlight_check_fb(struct backlight_device *bl,
struct fb_info *info)
{
- struct pwm_bl_data *pb = dev_get_drvdata(>dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
return !pb->check_fb || pb->check_fb(pb->dev, info);
}
@@ -264,7 +264,7 @@ err_alloc:
static int pwm_backlight_remove(struct platform_device *pdev)
{
struct backlight_device *bl = platform_get_drvdata(pdev);
- struct pwm_bl_data *pb = dev_get_drvdata(>dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
backlight_device_unregister(bl);
pwm_config(pb->pwm, 0, pb->period);
@@ -278,7 +278,7 @@ static int pwm_backlight_remove(struct platform_device
*pdev)
static int pwm_backlight_suspend(struct device *dev)
{
struct backlight_device *bl = dev_get_drvdata(dev);
- struct pwm_bl_data *pb = dev_get_drvdata(>dev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
if (pb->notify)
pb->notify(pb->dev, 0);
--
1.7.2.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/6] backlight: aat2870: use bl_get_data instead of dev_get_drvdata
Use the wrapper function for getting the driver data using
backlight_device instead of using dev_get_drvdata with >dev,
so we can directly pass a struct backlight_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/aat2870_bl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/aat2870_bl.c
b/drivers/video/backlight/aat2870_bl.c
index 7ff7522..c6fc668 100644
--- a/drivers/video/backlight/aat2870_bl.c
+++ b/drivers/video/backlight/aat2870_bl.c
@@ -74,7 +74,7 @@ static int aat2870_bl_get_brightness(struct backlight_device
*bd)
static int aat2870_bl_update_status(struct backlight_device *bd)
{
- struct aat2870_bl_driver_data *aat2870_bl = dev_get_drvdata(>dev);
+ struct aat2870_bl_driver_data *aat2870_bl = bl_get_data(bd);
struct aat2870_data *aat2870 =
dev_get_drvdata(aat2870_bl->pdev->dev.parent);
int brightness = bd->props.brightness;
--
1.7.2.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 11/11] backlight: lms501kf03: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/lms501kf03.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lms501kf03.c
b/drivers/video/backlight/lms501kf03.c
index f904abc..d00b13b 100644
--- a/drivers/video/backlight/lms501kf03.c
+++ b/drivers/video/backlight/lms501kf03.c
@@ -370,7 +370,7 @@ static int lms501kf03_probe(struct spi_device *spi)
lcd->power = FB_BLANK_UNBLANK;
}
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
dev_info(>dev, "lms501kf03 panel driver has been probed.\n");
@@ -379,7 +379,7 @@ static int lms501kf03_probe(struct spi_device *spi)
static int lms501kf03_remove(struct spi_device *spi)
{
- struct lms501kf03 *lcd = dev_get_drvdata(>dev);
+ struct lms501kf03 *lcd = spi_get_drvdata(spi);
lms501kf03_power(lcd, FB_BLANK_POWERDOWN);
lcd_device_unregister(lcd->ld);
@@ -391,7 +391,7 @@ static int lms501kf03_remove(struct spi_device *spi)
static int lms501kf03_suspend(struct spi_device *spi, pm_message_t mesg)
{
- struct lms501kf03 *lcd = dev_get_drvdata(>dev);
+ struct lms501kf03 *lcd = spi_get_drvdata(spi);
dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
@@ -404,7 +404,7 @@ static int lms501kf03_suspend(struct spi_device *spi,
pm_message_t mesg)
static int lms501kf03_resume(struct spi_device *spi)
{
- struct lms501kf03 *lcd = dev_get_drvdata(>dev);
+ struct lms501kf03 *lcd = spi_get_drvdata(spi);
lcd->power = FB_BLANK_POWERDOWN;
@@ -417,7 +417,7 @@ static int lms501kf03_resume(struct spi_device *spi)
void lms501kf03_shutdown(struct spi_device *spi)
{
- struct lms501kf03 *lcd = dev_get_drvdata(>dev);
+ struct lms501kf03 *lcd = spi_get_drvdata(spi);
lms501kf03_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.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 10/11] backlight: corgi_lcd: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/corgi_lcd.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index e323fcb..77c81f8 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -460,7 +460,7 @@ static const struct backlight_ops corgi_bl_ops = {
#ifdef CONFIG_PM
static int corgi_lcd_suspend(struct spi_device *spi, pm_message_t state)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = spi_get_drvdata(spi);
corgibl_flags |= CORGIBL_SUSPENDED;
corgi_bl_set_intensity(lcd, 0);
@@ -470,7 +470,7 @@ static int corgi_lcd_suspend(struct spi_device *spi,
pm_message_t state)
static int corgi_lcd_resume(struct spi_device *spi)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = spi_get_drvdata(spi);
corgibl_flags &= ~CORGIBL_SUSPENDED;
corgi_lcd_set_power(lcd->lcd_dev, FB_BLANK_UNBLANK);
@@ -577,7 +577,7 @@ static int corgi_lcd_probe(struct spi_device *spi)
lcd->kick_battery = pdata->kick_battery;
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
corgi_lcd_set_power(lcd->lcd_dev, FB_BLANK_UNBLANK);
backlight_update_status(lcd->bl_dev);
@@ -594,7 +594,7 @@ err_unregister_lcd:
static int corgi_lcd_remove(struct spi_device *spi)
{
- struct corgi_lcd *lcd = dev_get_drvdata(>dev);
+ struct corgi_lcd *lcd = spi_get_drvdata(spi);
lcd->bl_dev->props.power = FB_BLANK_UNBLANK;
lcd->bl_dev->props.brightness = 0;
--
1.7.2.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/11] backlight: tosa: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/tosa_lcd.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index 96bae94..666fe25 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -193,7 +193,7 @@ static int tosa_lcd_probe(struct spi_device *spi)
return ret;
data->spi = spi;
- dev_set_drvdata(>dev, data);
+ spi_set_drvdata(spi, data);
ret = devm_gpio_request_one(>dev, TOSA_GPIO_TG_ON,
GPIOF_OUT_INIT_LOW, "tg #pwr");
@@ -220,13 +220,13 @@ static int tosa_lcd_probe(struct spi_device *spi)
err_register:
tosa_lcd_tg_off(data);
err_gpio_tg:
- dev_set_drvdata(>dev, NULL);
+ spi_set_drvdata(spi, NULL);
return ret;
}
static int tosa_lcd_remove(struct spi_device *spi)
{
- struct tosa_lcd_data *data = dev_get_drvdata(>dev);
+ struct tosa_lcd_data *data = spi_get_drvdata(spi);
lcd_device_unregister(data->lcd);
@@ -235,7 +235,7 @@ static int tosa_lcd_remove(struct spi_device *spi)
tosa_lcd_tg_off(data);
- dev_set_drvdata(>dev, NULL);
+ spi_set_drvdata(spi, NULL);
return 0;
}
@@ -243,7 +243,7 @@ static int tosa_lcd_remove(struct spi_device *spi)
#ifdef CONFIG_PM
static int tosa_lcd_suspend(struct spi_device *spi, pm_message_t state)
{
- struct tosa_lcd_data *data = dev_get_drvdata(>dev);
+ struct tosa_lcd_data *data = spi_get_drvdata(spi);
tosa_lcd_tg_off(data);
@@ -252,7 +252,7 @@ static int tosa_lcd_suspend(struct spi_device *spi,
pm_message_t state)
static int tosa_lcd_resume(struct spi_device *spi)
{
- struct tosa_lcd_data *data = dev_get_drvdata(>dev);
+ struct tosa_lcd_data *data = spi_get_drvdata(spi);
tosa_lcd_tg_init(data);
if (POWER_IS_ON(data->lcd_power))
--
1.7.2.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 08/11] backlight: vgg2432a4: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/vgg2432a4.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/vgg2432a4.c
b/drivers/video/backlight/vgg2432a4.c
index 45e81b4..84d582f 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -208,12 +208,11 @@ static int vgg2432a4_lcd_init(struct ili9320 *lcd,
#ifdef CONFIG_PM
static int vgg2432a4_suspend(struct spi_device *spi, pm_message_t state)
{
- return ili9320_suspend(dev_get_drvdata(>dev), state);
+ return ili9320_suspend(spi_get_drvdata(spi), state);
}
-
static int vgg2432a4_resume(struct spi_device *spi)
{
- return ili9320_resume(dev_get_drvdata(>dev));
+ return ili9320_resume(spi_get_drvdata(spi));
}
#else
#define vgg2432a4_suspend NULL
@@ -242,12 +241,12 @@ static int vgg2432a4_probe(struct spi_device *spi)
static int vgg2432a4_remove(struct spi_device *spi)
{
- return ili9320_remove(dev_get_drvdata(>dev));
+ return ili9320_remove(spi_get_drvdata(spi));
}
static void vgg2432a4_shutdown(struct spi_device *spi)
{
- ili9320_shutdown(dev_get_drvdata(>dev));
+ ili9320_shutdown(spi_get_drvdata(spi));
}
static struct spi_driver vgg2432a4_driver = {
--
1.7.2.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/11] backlight: ams369fg06: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/ams369fg06.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/ams369fg06.c
b/drivers/video/backlight/ams369fg06.c
index 72d71e0..bd8a320 100644
--- a/drivers/video/backlight/ams369fg06.c
+++ b/drivers/video/backlight/ams369fg06.c
@@ -513,7 +513,7 @@ static int ams369fg06_probe(struct spi_device *spi)
lcd->power = FB_BLANK_UNBLANK;
}
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
dev_info(>dev, "ams369fg06 panel driver has been probed.\n");
@@ -526,7 +526,7 @@ out_lcd_unregister:
static int ams369fg06_remove(struct spi_device *spi)
{
- struct ams369fg06 *lcd = dev_get_drvdata(>dev);
+ struct ams369fg06 *lcd = spi_get_drvdata(spi);
ams369fg06_power(lcd, FB_BLANK_POWERDOWN);
backlight_device_unregister(lcd->bd);
@@ -538,7 +538,7 @@ static int ams369fg06_remove(struct spi_device *spi)
#if defined(CONFIG_PM)
static int ams369fg06_suspend(struct spi_device *spi, pm_message_t mesg)
{
- struct ams369fg06 *lcd = dev_get_drvdata(>dev);
+ struct ams369fg06 *lcd = spi_get_drvdata(spi);
dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
@@ -551,7 +551,7 @@ static int ams369fg06_suspend(struct spi_device *spi,
pm_message_t mesg)
static int ams369fg06_resume(struct spi_device *spi)
{
- struct ams369fg06 *lcd = dev_get_drvdata(>dev);
+ struct ams369fg06 *lcd = spi_get_drvdata(spi);
lcd->power = FB_BLANK_POWERDOWN;
@@ -564,7 +564,7 @@ static int ams369fg06_resume(struct spi_device *spi)
static void ams369fg06_shutdown(struct spi_device *spi)
{
- struct ams369fg06 *lcd = dev_get_drvdata(>dev);
+ struct ams369fg06 *lcd = spi_get_drvdata(spi);
ams369fg06_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.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/11] backlight: lms283gf05: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/lms283gf05.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lms283gf05.c
b/drivers/video/backlight/lms283gf05.c
index 55819b3..4eec472 100644
--- a/drivers/video/backlight/lms283gf05.c
+++ b/drivers/video/backlight/lms283gf05.c
@@ -180,7 +180,7 @@ static int lms283gf05_probe(struct spi_device *spi)
st->spi = spi;
st->ld = ld;
- dev_set_drvdata(>dev, st);
+ spi_set_drvdata(spi, st);
/* kick in the LCD */
if (pdata)
@@ -192,7 +192,7 @@ static int lms283gf05_probe(struct spi_device *spi)
static int lms283gf05_remove(struct spi_device *spi)
{
- struct lms283gf05_state *st = dev_get_drvdata(>dev);
+ struct lms283gf05_state *st = spi_get_drvdata(spi);
lcd_device_unregister(st->ld);
--
1.7.2.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 05/11] backlight: tdo24m: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/tdo24m.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index ad2325f..0016208 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -390,7 +390,7 @@ static int tdo24m_probe(struct spi_device *spi)
if (IS_ERR(lcd->lcd_dev))
return PTR_ERR(lcd->lcd_dev);
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
err = tdo24m_power(lcd, FB_BLANK_UNBLANK);
if (err)
goto out_unregister;
@@ -404,7 +404,7 @@ out_unregister:
static int tdo24m_remove(struct spi_device *spi)
{
- struct tdo24m *lcd = dev_get_drvdata(>dev);
+ struct tdo24m *lcd = spi_get_drvdata(spi);
tdo24m_power(lcd, FB_BLANK_POWERDOWN);
lcd_device_unregister(lcd->lcd_dev);
@@ -415,14 +415,14 @@ static int tdo24m_remove(struct spi_device *spi)
#ifdef CONFIG_PM
static int tdo24m_suspend(struct spi_device *spi, pm_message_t state)
{
- struct tdo24m *lcd = dev_get_drvdata(>dev);
+ struct tdo24m *lcd = spi_get_drvdata(spi);
return tdo24m_power(lcd, FB_BLANK_POWERDOWN);
}
static int tdo24m_resume(struct spi_device *spi)
{
- struct tdo24m *lcd = dev_get_drvdata(>dev);
+ struct tdo24m *lcd = spi_get_drvdata(spi);
return tdo24m_power(lcd, FB_BLANK_UNBLANK);
}
@@ -434,7 +434,7 @@ static int tdo24m_resume(struct spi_device *spi)
/* Power down all displays on reboot, poweroff or halt */
static void tdo24m_shutdown(struct spi_device *spi)
{
- struct tdo24m *lcd = dev_get_drvdata(>dev);
+ struct tdo24m *lcd = spi_get_drvdata(spi);
tdo24m_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.7-nohz1
Hi, On Thu, Dec 20, 2012 at 11:32 AM, Frederic Weisbecker wrote: > Hi, > > So this is a new version of the nohz cpusets based on 3.7, except it's not > using > cpusets anymore and I actually based it on the middle of the 3.8 merge window > in order to get latest upstream full dynticks preparatory work: cputime > cleanups, > RCU user mode, context tracking subsystem, nohz code consolidation, ... > > So the big changes since the last nohz cpuset release are: > > * printk now uses irq work so it doesn't rely on the tick anymore (provided > your arch implements irq work with IPIs or alike). This chunk has been > proposed > for the 3.8 merge window: https://lkml.org/lkml/2012/12/17/177 > May be Linus will pull, may be not. We'll see. In any case I've included it > in this tree > but I'm not reposting this part of the patchset to avoid spamming you. > > * cputime doesn't rely on IPIs anymore. Now the reader does a special > computation to > remotely get the tickless cputime. > > * No more cpusets interface. Paul McKenney suggested me to start with a boot > time > kernel parameter to define the full dynticks cpumask. And he was totally > right, it > makes the code much more simple. That's a good way to start and to make the > mainlining > easier. We can still add a runtime configuration later if necessary. It would be nice to have the runtime configuration ability. A percpu control file such as /sys/devices/system/cpu/cpuX/isol could configure that cpu with different levels of isolation. Users could echo bitmasks where each bit is associated with a level of isolation. echo 0 disables all isolation. Bit 1 disables RCU callbacks on that CPU, bit 2 isolates the CPU from the general scheduler just like isolcpus boot argument does, bit 3 pushes all irqs away, bit 4 turns off the ticks etc. I always hoped that someone will make isolcpus a runtime option so I guess it is time to get my hands dirty. Any pointers for this? > > * Now there is always a CPU handling the timekeeping. This can be further > optimized > and more power-friendly, I really did something simple-stupid. I guess we'll > try to get > that into a better shape with Hakan. But at least the timekeeping now works. Will look into it. > > * It uses the new RCU callbacks offlining feature. This way a full dynticks > CPU doesn't > need to keep the tick to handle local callbacks. This is still very > experimental though. > > * No more specific IPI vector for full dynticks. We just use the scheduler > ipi. > > The branch is: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > 3.7-nohz1 > > There is still quite some work to do. > > == How to use? == > > Select: > CONFIG_NO_HZ > CONFIG_RCU_USER_QS > CONFIG_VIRT_CPU_ACCOUNTING_GEN > CONFIG_RCU_NOCB_CPU > CONFIG_NO_HZ_FULL > > You always need at least one timekeeping CPU. > > Let's imagine you have 4 CPUs. We keep the CPU 0 to offline RCU callbacks > there and to > handle the timekeeping. We set the rest as full dynticks. So you need the > following kernel > parameters: > > rcu_nocbs=1-3 full_nohz=1-3 > > (Note rcu_nocbs value must always be the same as full_nohz). > > Now if you want proper isolation you need to: > > * Migrate your processes adequately > * Migrate your irqs to CPU 0 > * Migrate the RCU nocb threads to CPU 0. Example with the above configuration: > > for p in $(ps -o pid= -C rcuo1,rcuo2,rcuo3) > do > taskset -cp 0 $p > done > > Then run what you want on the full dynticks CPUs. For best results, run 1 task > per CPU, mostly in userspace and mostly CPU bound (otherwise more IO = more > kernel > mode execution = more chances to get IPIs, tick restarted, workqueues, > kthreads, etc...) > > This page contains a good reminder for those interested in CPU isolation: > https://github.com/gby/linux/wiki > > But keep in mind that my tree is not yet ready for serious production. > > Happy Christmas, new year or whatever end of the world. > --- > > Frederic Weisbecker (32): > irq_work: Fix racy IRQ_WORK_BUSY flag setting > irq_work: Fix racy check on work pending flag > irq_work: Remove CONFIG_HAVE_IRQ_WORK > nohz: Add API to check tick state > irq_work: Don't stop the tick with pending works > irq_work: Make self-IPIs optable > printk: Wake up klogd using irq_work > Merge branch 'nohz/printk-v8' into 3.7-nohz1-stage > context_tracking: Add comments on interface and internals > cputime: Generic on-demand virtual cputime accounting > cputime: Allow dynamic switch between tick/virtual based cputime > accounting > cputime: Use accessors to read task cputime stats > cputime: Safely read cputime of full dynticks CPUs > nohz: Basic full dynticks interface > nohz: Assign timekeeping duty to a non-full-nohz CPU > nohz: Trace timekeeping update > nohz: Wake up full dynticks
[PATCH 04/11] backlight: ltv350qv: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/ltv350qv.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/ltv350qv.c
b/drivers/video/backlight/ltv350qv.c
index 226d813..c0b4b8f 100644
--- a/drivers/video/backlight/ltv350qv.c
+++ b/drivers/video/backlight/ltv350qv.c
@@ -252,7 +252,7 @@ static int ltv350qv_probe(struct spi_device *spi)
if (ret)
goto out_unregister;
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
return 0;
@@ -263,7 +263,7 @@ out_unregister:
static int ltv350qv_remove(struct spi_device *spi)
{
- struct ltv350qv *lcd = dev_get_drvdata(>dev);
+ struct ltv350qv *lcd = spi_get_drvdata(spi);
ltv350qv_power(lcd, FB_BLANK_POWERDOWN);
lcd_device_unregister(lcd->ld);
@@ -274,14 +274,14 @@ static int ltv350qv_remove(struct spi_device *spi)
#ifdef CONFIG_PM
static int ltv350qv_suspend(struct spi_device *spi, pm_message_t state)
{
- struct ltv350qv *lcd = dev_get_drvdata(>dev);
+ struct ltv350qv *lcd = spi_get_drvdata(spi);
return ltv350qv_power(lcd, FB_BLANK_POWERDOWN);
}
static int ltv350qv_resume(struct spi_device *spi)
{
- struct ltv350qv *lcd = dev_get_drvdata(>dev);
+ struct ltv350qv *lcd = spi_get_drvdata(spi);
return ltv350qv_power(lcd, FB_BLANK_UNBLANK);
}
@@ -293,7 +293,7 @@ static int ltv350qv_resume(struct spi_device *spi)
/* Power down all displays on reboot, poweroff or halt */
static void ltv350qv_shutdown(struct spi_device *spi)
{
- struct ltv350qv *lcd = dev_get_drvdata(>dev);
+ struct ltv350qv *lcd = spi_get_drvdata(spi);
ltv350qv_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.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 03/11] backlight: s6e63m0: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device
Signed-off-by: Jingoo Han
---
drivers/video/backlight/s6e63m0.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/s6e63m0.c
b/drivers/video/backlight/s6e63m0.c
index 0969a4048..2126b96 100644
--- a/drivers/video/backlight/s6e63m0.c
+++ b/drivers/video/backlight/s6e63m0.c
@@ -793,7 +793,7 @@ static int s6e63m0_probe(struct spi_device *spi)
lcd->power = FB_BLANK_UNBLANK;
}
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
dev_info(>dev, "s6e63m0 panel driver has been probed.\n");
@@ -806,7 +806,7 @@ out_lcd_unregister:
static int s6e63m0_remove(struct spi_device *spi)
{
- struct s6e63m0 *lcd = dev_get_drvdata(>dev);
+ struct s6e63m0 *lcd = spi_get_drvdata(spi);
s6e63m0_power(lcd, FB_BLANK_POWERDOWN);
device_remove_file(>dev, _attr_gamma_table);
@@ -820,7 +820,7 @@ static int s6e63m0_remove(struct spi_device *spi)
#if defined(CONFIG_PM)
static int s6e63m0_suspend(struct spi_device *spi, pm_message_t mesg)
{
- struct s6e63m0 *lcd = dev_get_drvdata(>dev);
+ struct s6e63m0 *lcd = spi_get_drvdata(spi);
dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
@@ -833,7 +833,7 @@ static int s6e63m0_suspend(struct spi_device *spi,
pm_message_t mesg)
static int s6e63m0_resume(struct spi_device *spi)
{
- struct s6e63m0 *lcd = dev_get_drvdata(>dev);
+ struct s6e63m0 *lcd = spi_get_drvdata(spi);
lcd->power = FB_BLANK_POWERDOWN;
@@ -847,7 +847,7 @@ static int s6e63m0_resume(struct spi_device *spi)
/* Power down all displays on reboot, poweroff or halt. */
static void s6e63m0_shutdown(struct spi_device *spi)
{
- struct s6e63m0 *lcd = dev_get_drvdata(>dev);
+ struct s6e63m0 *lcd = spi_get_drvdata(spi);
s6e63m0_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.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: new architectures, time_t __kernel_long_t
On Thu, Dec 20, 2012 at 09:05:30PM -0800, H. Peter Anvin wrote: > >... as long as we do not have typedef __kernel_foo_t foo_t in linux/types.h. > > > > In the case of things like nlink_t and dev_t I would suggest we > explicitly call out the types as kernel and user. I would suggest > knlink_t and unlink_t but the latter made me want to stab my eyes > out due to its confusion potential, so I wonder if we should > establish a new convention with _kt (kernel type) and _ut (user > type) suffixes, so nlink_kt and nlink_ut, alternatively one could > consider k_nlink_t and u_nlink_t. What the hell for? _Which_ userland nlink_t, anyway? We have quite a few struct stat variants in there. Sorry, but I really don't see any point in that, and a lot of potential for confusion. Marshalling is about the only thing we need the userland ones for and the code doing it is just fine with the only object of that type in sight being the field of e.g. struct stat with given name... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/11] backlight: ld9040: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/ld9040.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
index 12b5c01..24f2c9a 100644
--- a/drivers/video/backlight/ld9040.c
+++ b/drivers/video/backlight/ld9040.c
@@ -755,7 +755,7 @@ static int ld9040_probe(struct spi_device *spi)
lcd->power = FB_BLANK_UNBLANK;
}
- dev_set_drvdata(>dev, lcd);
+ spi_set_drvdata(spi, lcd);
dev_info(>dev, "ld9040 panel driver has been probed.\n");
return 0;
@@ -770,7 +770,7 @@ out_free_regulator:
static int ld9040_remove(struct spi_device *spi)
{
- struct ld9040 *lcd = dev_get_drvdata(>dev);
+ struct ld9040 *lcd = spi_get_drvdata(spi);
ld9040_power(lcd, FB_BLANK_POWERDOWN);
backlight_device_unregister(lcd->bd);
@@ -783,7 +783,7 @@ static int ld9040_remove(struct spi_device *spi)
#if defined(CONFIG_PM)
static int ld9040_suspend(struct spi_device *spi, pm_message_t mesg)
{
- struct ld9040 *lcd = dev_get_drvdata(>dev);
+ struct ld9040 *lcd = spi_get_drvdata(spi);
dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
@@ -796,7 +796,7 @@ static int ld9040_suspend(struct spi_device *spi,
pm_message_t mesg)
static int ld9040_resume(struct spi_device *spi)
{
- struct ld9040 *lcd = dev_get_drvdata(>dev);
+ struct ld9040 *lcd = spi_get_drvdata(spi);
lcd->power = FB_BLANK_POWERDOWN;
@@ -810,7 +810,7 @@ static int ld9040_resume(struct spi_device *spi)
/* Power down all displays on reboot, poweroff or halt. */
static void ld9040_shutdown(struct spi_device *spi)
{
- struct ld9040 *lcd = dev_get_drvdata(>dev);
+ struct ld9040 *lcd = spi_get_drvdata(spi);
ld9040_power(lcd, FB_BLANK_POWERDOWN);
}
--
1.7.2.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 01/11] backlight: l4f00242t03: use spi_get_drvdata and spi_set_drvdata
Use the wrapper functions for getting and setting the driver data
using spi_device instead of using dev_{get|set}_drvdata with
>dev, so we can directly pass a struct spi_device.
Signed-off-by: Jingoo Han
---
drivers/video/backlight/l4f00242t03.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/l4f00242t03.c
b/drivers/video/backlight/l4f00242t03.c
index 9a35196..9bef9cf 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -49,7 +49,7 @@ static void l4f00242t03_reset(unsigned int gpio)
static void l4f00242t03_lcd_init(struct spi_device *spi)
{
struct l4f00242t03_pdata *pdata = spi->dev.platform_data;
- struct l4f00242t03_priv *priv = dev_get_drvdata(>dev);
+ struct l4f00242t03_priv *priv = spi_get_drvdata(spi);
const u16 cmd[] = { 0x36, param(0), 0x3A, param(0x60) };
dev_dbg(>dev, "initializing LCD\n");
@@ -70,7 +70,7 @@ static void l4f00242t03_lcd_init(struct spi_device *spi)
static void l4f00242t03_lcd_powerdown(struct spi_device *spi)
{
struct l4f00242t03_pdata *pdata = spi->dev.platform_data;
- struct l4f00242t03_priv *priv = dev_get_drvdata(>dev);
+ struct l4f00242t03_priv *priv = spi_get_drvdata(spi);
dev_dbg(>dev, "Powering down LCD\n");
@@ -168,7 +168,7 @@ static int l4f00242t03_probe(struct spi_device *spi)
return -ENOMEM;
}
- dev_set_drvdata(>dev, priv);
+ spi_set_drvdata(spi, priv);
spi->bits_per_word = 9;
spi_setup(spi);
@@ -231,12 +231,12 @@ err1:
static int l4f00242t03_remove(struct spi_device *spi)
{
- struct l4f00242t03_priv *priv = dev_get_drvdata(>dev);
+ struct l4f00242t03_priv *priv = spi_get_drvdata(spi);
l4f00242t03_lcd_power_set(priv->ld, FB_BLANK_POWERDOWN);
lcd_device_unregister(priv->ld);
- dev_set_drvdata(>dev, NULL);
+ spi_set_drvdata(spi, NULL);
regulator_put(priv->io_reg);
regulator_put(priv->core_reg);
@@ -246,7 +246,7 @@ static int l4f00242t03_remove(struct spi_device *spi)
static void l4f00242t03_shutdown(struct spi_device *spi)
{
- struct l4f00242t03_priv *priv = dev_get_drvdata(>dev);
+ struct l4f00242t03_priv *priv = spi_get_drvdata(spi);
if (priv)
l4f00242t03_lcd_power_set(priv->ld, FB_BLANK_POWERDOWN);
--
1.7.2.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 02/24] cputime: Generic on-demand virtual cputime accounting
On Thu, 2012-12-20 at 19:32 +0100, Frederic Weisbecker wrote:
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 293b202..da0a9e7 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -3,6 +3,7 @@
> #include
> #include
> #include
> +#include
> #include "sched.h"
>
>
> @@ -495,10 +496,24 @@ void vtime_task_switch(struct task_struct *prev)
> #ifndef __ARCH_HAS_VTIME_ACCOUNT
> void vtime_account(struct task_struct *tsk)
> {
> - if (in_interrupt() || !is_idle_task(tsk))
> - vtime_account_system(tsk);
> - else
> - vtime_account_idle(tsk);
> + if (!in_interrupt()) {
> + /*
> + * If we interrupted user, context_tracking_in_user()
> + * is 1 because the context tracking don't hook
> + * on irq entry/exit. This way we know if
> + * we need to flush user time on kernel entry.
> + */
> + if (context_tracking_in_user()) {
> + vtime_account_user(tsk);
> + return;
> + }
> +
> + if (is_idle_task(tsk)) {
> + vtime_account_idle(tsk);
> + return;
> + }
> + }
> + vtime_account_system(tsk);
> }
> EXPORT_SYMBOL_GPL(vtime_account);
> #endif /* __ARCH_HAS_VTIME_ACCOUNT */
> @@ -586,4 +601,72 @@ void thread_group_cputime_adjusted(struct task_struct
> *p, cputime_t *ut, cputime
> thread_group_cputime(p, );
> cputime_adjust(, >signal->prev_cputime, ut, st);
> }
> -#endif
Deleted #endif here.
> +
> +#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
Added #ifdef here.
> +static DEFINE_PER_CPU(long, last_jiffies) = INITIAL_JIFFIES;
> +
> +static cputime_t get_vtime_delta(void)
> +{
> + long delta;
> +
> + delta = jiffies - __this_cpu_read(last_jiffies);
> + __this_cpu_add(last_jiffies, delta);
> +
> + return jiffies_to_cputime(delta);
> +}
> +
> +void vtime_account_system(struct task_struct *tsk)
> +{
> + cputime_t delta_cpu = get_vtime_delta();
> +
> + account_system_time(tsk, irq_count(), delta_cpu,
> cputime_to_scaled(delta_cpu));
> +}
> +
> +void vtime_account_user(struct task_struct *tsk)
> +{
> + cputime_t delta_cpu = get_vtime_delta();
> +
> + /*
> + * This is an unfortunate hack: if we flush user time only on
> + * irq entry, we miss the jiffies update and the time is spuriously
> + * accounted to system time.
> + */
> + if (context_tracking_in_user())
> + account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
> +}
> +
> +void vtime_account_idle(struct task_struct *tsk)
> +{
> + cputime_t delta_cpu = get_vtime_delta();
> +
> + account_idle_time(delta_cpu);
> +}
> +
> +static int __cpuinit vtime_cpu_notify(struct notifier_block *self,
> + unsigned long action, void *hcpu)
> +{
> + long cpu = (long)hcpu;
> + long *last_jiffies_cpu = per_cpu_ptr(_jiffies, cpu);
> +
> + switch (action) {
> + case CPU_UP_PREPARE:
> + case CPU_UP_PREPARE_FROZEN:
> + /*
> + * CHECKME: ensure that's visible by the CPU
> + * once it wakes up
> + */
> + *last_jiffies_cpu = jiffies;
> + default:
> + break;
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> +static int __init init_vtime(void)
> +{
> + cpu_notifier(vtime_cpu_notify, 0);
> + return 0;
> +}
> +early_initcall(init_vtime);
> +#endif /* CONFIG_VIRT_CPU_ACCOUNTING_GEN */
Added #endif here
Hmm, missing #endif somewhere. Must explain my error message:
kernel/sched/cputime.c:448:0: error: unterminated #else
Looks like a possible mismerge.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat_dget() fails
2012/12/20, OGAWA Hirofumi : > Namjae Jeon writes: > >>> Okay, We will check how we can consolidate the 2 paths to avoid any >>> issue. >> Hi OGAWA. >> >> On checking fat_search_long() logic, it is observed that it performs >> name based lookup of the entries in a given directory. >> In fat_get_parent(), we do not have such information to use the >> existing API to reconstruct the parent inode. >> Could you give me some hint or guide to consolidate smoothly >> fat_search_long and current traverse_logic ? > > Hm, start with copy of fat_search_long() and refactoring it. With it, we > will be able to avoid the fixed bugs. > > After that, we might be able to merge those somehow. Well, I'm not > pretty sure without doing it actually though. Hi OGAWA. When we checked to merge it with fat_search_long, we really did not find any possibility of code reusing for fat_traverse_cluster. It will not be proper ? In case of fat_search_long()-> it is performing a name based lookup in a particular directory. While for reconnection with parent from NFS ? we do not have the name of the parent directory. We are relying on ‘i_pos’ ? on disk position of directory entry. So, on first request for lookup for “..” (i.e if we call fat_search_long(child_dir->d_inode, MSDOS_DOTDOT,2,slot_info) it will return the directory entry for “..” itself. From this entry we can read the “log start” which is the starting cluster of the parent directory, but instead we need the “directory entry” where this is stored. So, from this level we need to go further one level up and read the parent ->parent-> cluster. After reading that cluster, we need to do a lookup of the “required ipos” in this directory block. i.e., if the path is A/B/C ? and we call the get_parent() from ‘C’. We need to read the directory block contents of ‘A’ and from those ‘directory entries' compare the log_start with the log_start value of B, which was obtained by doing a lookup “..” in C. So, Instead of it, we suggest we fix the “infinite-loop” condition in fat_traverse_logic and retain the code. of course, we will test it with corrupted FATfs. Please share your thoughts on this. Thanks. > > Thanks. > -- > OGAWA Hirofumi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat_dget() fails
2012/12/21, Namjae Jeon : > 2012/12/20, OGAWA Hirofumi : >> Namjae Jeon writes: >> Okay, We will check how we can consolidate the 2 paths to avoid any issue. >>> Hi OGAWA. >>> >>> On checking fat_search_long() logic, it is observed that it performs >>> name based lookup of the entries in a given directory. >>> In fat_get_parent(), we do not have such information to use the >>> existing API to reconstruct the parent inode. >>> Could you give me some hint or guide to consolidate smoothly >>> fat_search_long and current traverse_logic ? >> >> Hm, start with copy of fat_search_long() and refactoring it. With it, we >> will be able to avoid the fixed bugs. >> >> After that, we might be able to merge those somehow. Well, I'm not >> pretty sure without doing it actually though. Hi OGAWA. When we checked to merge it with fat_search_long, we really did not find any possibility of code reusing for fat_traverse_cluster. It will not be proper. In case of fat_search_long()-> it is performing a name based lookup in a particular directory. While for reconnection with parent from NFS, we do not have the name of the parent directory. We are relying on ‘i_pos’ on disk position of directory entry. So, on first request for lookup for “..” (i.e if we call fat_search_long(child_dir->d_inode, MSDOS_DOTDOT,2,slot_info) it will return the directory entry for “..” itself. From this entry we can read the “log start” which is the starting cluster of the parent directory, but instead we need the “directory entry” where this is stored. So, from this level we need to go further one level up and read the parent ->parent-> cluster. After reading that cluster, we need to do a lookup of the “required ipos” in this directory block. i.e., if the path is A/B/C and we call the get_parent() from ‘C’. We need to read the directory block contents of ‘A’ and from those ‘directory entries' compare the log_start with the log_start value of B, which was obtained by doing a lookup “..” in C. So, Instead of it, we suggest we fix the “infinite-loop” condition in fat_traverse_logic and retain the code. of course, we will test it with corrupted FATfs. Please share your thoughts on this. Thanks. >> >> Thanks. >> -- >> OGAWA Hirofumi >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 09/11] x86/head64.c: Early update ucode in 64-bit
> > From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf > Of > > Yinghai Lu > > On Thu, Dec 20, 2012 at 11:48 AM, Fenghua Yu > > wrote: > > > From: Fenghua Yu > > > > > > This updates ucode on BSP in 64-bit mode. Paging and virtual > address > > are > > > working now. > > > > > > Signed-off-by: Fenghua Yu > > > --- > > > arch/x86/kernel/head64.c | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > > > index e1cb611..1ccbaf1 100644 > > > --- a/arch/x86/kernel/head64.c > > > +++ b/arch/x86/kernel/head64.c > > > @@ -26,6 +26,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > /* > > > * Manage page tables very early on. > > > @@ -179,6 +180,11 @@ void __init x86_64_start_kernel(char * > > real_mode_data) > > > } > > > load_idt((const struct desc_ptr *)_descr); > > > > > > + /* > > > +* Load microcode early on BSP. > > > +*/ > > > + load_ucode_bsp(__va(real_mode_data)); > > > + > > > copy_bootdata(__va(real_mode_data)); > > > > can you make load_ucode_bsp take boot_param directly instead of > > real_mode_data. ? > > > > could be > > > > > > copy_bootdata(__va(real_mode_data)); > > + > > +/* Load microcode early on BSP. */ > > + load_ucode_bsp(_params); > > + > > > > because copy_bootdata, already copy boot_params... > > > > Thanks > > > > Yinghai > > That's right. Will fix this. I'll call load_ucode_bsp(void) though which will access the global boot_params variable. Thanks. -Fenghua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: new architectures, time_t __kernel_long_t
On 12/20/2012 09:02 PM, Al Viro wrote: On Thu, Dec 20, 2012 at 09:00:27PM -0800, H. Peter Anvin wrote: On 12/20/2012 08:57 PM, Al Viro wrote: On Wed, Nov 14, 2012 at 12:18:01PM +, Arnd Bergmann wrote: The other types that are used as 64 bit on x32 are ino_t, nlink_t, size_t, ssize_t, ptrdiff_t, and off_t. *Kernel-side* we should not give a damn about the userland nlink_t, period. Making it architecture-dependent had been a bad mistake that essentially made nlink_t useless for the kernel. That mistake had been fixed; please, do not bring it back. If some userland structure needs to include a field encoding nlink_t values, please use an explicitly-sized type when refering to it kernel-side. We should never use userland types per se. We can use __kernel_*_t typedefs to make the kernel headers neater if it makes sense, but that is often not even necessary. ... as long as we do not have typedef __kernel_foo_t foo_t in linux/types.h. In the case of things like nlink_t and dev_t I would suggest we explicitly call out the types as kernel and user. I would suggest knlink_t and unlink_t but the latter made me want to stab my eyes out due to its confusion potential, so I wonder if we should establish a new convention with _kt (kernel type) and _ut (user type) suffixes, so nlink_kt and nlink_ut, alternatively one could consider k_nlink_t and u_nlink_t. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: new architectures, time_t __kernel_long_t
On Thu, Dec 20, 2012 at 09:00:27PM -0800, H. Peter Anvin wrote: > On 12/20/2012 08:57 PM, Al Viro wrote: > > On Wed, Nov 14, 2012 at 12:18:01PM +, Arnd Bergmann wrote: > > > >> The other types that are used as 64 bit on x32 are ino_t, nlink_t, > >> size_t, ssize_t, ptrdiff_t, and off_t. > > > > *Kernel-side* we should not give a damn about the userland nlink_t, period. > > Making it architecture-dependent had been a bad mistake that essentially > > made nlink_t useless for the kernel. That mistake had been fixed; please, > > do not bring it back. If some userland structure needs to include a field > > encoding nlink_t values, please use an explicitly-sized type when refering > > to it kernel-side. > > > > We should never use userland types per se. We can use __kernel_*_t > typedefs to make the kernel headers neater if it makes sense, but that > is often not even necessary. ... as long as we do not have typedef __kernel_foo_t foo_t in linux/types.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: new architectures, time_t __kernel_long_t
On 12/20/2012 08:57 PM, Al Viro wrote: > On Wed, Nov 14, 2012 at 12:18:01PM +, Arnd Bergmann wrote: > >> The other types that are used as 64 bit on x32 are ino_t, nlink_t, >> size_t, ssize_t, ptrdiff_t, and off_t. > > *Kernel-side* we should not give a damn about the userland nlink_t, period. > Making it architecture-dependent had been a bad mistake that essentially > made nlink_t useless for the kernel. That mistake had been fixed; please, > do not bring it back. If some userland structure needs to include a field > encoding nlink_t values, please use an explicitly-sized type when refering > to it kernel-side. > We should never use userland types per se. We can use __kernel_*_t typedefs to make the kernel headers neater if it makes sense, but that is often not even necessary. > The same should've been true for mode_t, but for historical reasons we > are using umode_t for just about everything and IMO we should kill the > last references to mode_t anywhere kernel-side (again, explicitly-sized > types for userland st_mode and friends on the last few architectures > still refering to mode_t there) and just rename umode_t to mode_t; I'm > sick and tired of playing whack-a-mole with code using (arch-dependent) > mode_t for kernel data. And no, it's not always harmless - we had rather > ugly bugs based on that. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new architectures, time_t __kernel_long_t
On Wed, Nov 14, 2012 at 12:18:01PM +, Arnd Bergmann wrote: > The other types that are used as 64 bit on x32 are ino_t, nlink_t, > size_t, ssize_t, ptrdiff_t, and off_t. *Kernel-side* we should not give a damn about the userland nlink_t, period. Making it architecture-dependent had been a bad mistake that essentially made nlink_t useless for the kernel. That mistake had been fixed; please, do not bring it back. If some userland structure needs to include a field encoding nlink_t values, please use an explicitly-sized type when refering to it kernel-side. The same should've been true for mode_t, but for historical reasons we are using umode_t for just about everything and IMO we should kill the last references to mode_t anywhere kernel-side (again, explicitly-sized types for userland st_mode and friends on the last few architectures still refering to mode_t there) and just rename umode_t to mode_t; I'm sick and tired of playing whack-a-mole with code using (arch-dependent) mode_t for kernel data. And no, it's not always harmless - we had rather ugly bugs based on that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] stack and heap are executable on x86_64
On 12/20/2012 07:00 PM, Kees Cook wrote: This change for pre-v3.5 creates a new exception table instead of trying to rewrite the old one. Since the tables are now relative, we can't actually set up an exception for things in stack and heap on x86_64 since the distance between the address and the table's .insn is more than INT_MAX. And if the table were moved into the stack or heap, then the fixup couldn't point back to the module's text segment. For v3.5 and later, I'm not sure what to do... So, mainly two things: - we need to fix the stack/heap markings. - it'd be nice to get test_nx back on its feet again. I just looked at a /sys/kernel/debug/kernel_page_tables dump and there are a bunch of pages which are RWX: 0x8800-0x88097000 604K RW GLB x pte 0x8809d000-0x8820 1420K RW GLB x pte 0x8820-0x88000100 14M RW PSE GLB x pmd 0x880001c0-0x880035e0 834M RW PSE GLB x pmd 0x880035e0-0x880035ffe000 2040K RW GLB x pte 0x880036ff7000-0x88003700 36K RW GLB x pte 0x88003700-0x88004000 144M RW PSE GLB x pmd 0x81c0-0x81cea000 936K RW GLB x pte 0x81dfd000-0x81e0 12K RW GLB x pte 0x81e0-0x82002M RW PSE GLB x pmd One particular piece of idiocy is that we tied marking the pages executable into the PAT system, which means that if it is executable anywhere in the kernel it is executable everywhere. That being said, I don't think that is the only thing at play here. On the other hand... do we *ever* have a legitimate reason to run code below the -2G point? If so we could/should probably mark those NX already at the higher paging levels... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 09/11] x86/head64.c: Early update ucode in 64-bit
> -Original Message- > From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of > Yinghai Lu > Sent: Thursday, December 20, 2012 8:10 PM > To: Yu, Fenghua > Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K; > Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86 > Subject: Re: [PATCH v4 09/11] x86/head64.c: Early update ucode in 64- > bit > > On Thu, Dec 20, 2012 at 11:48 AM, Fenghua Yu > wrote: > > From: Fenghua Yu > > > > This updates ucode on BSP in 64-bit mode. Paging and virtual address > are > > working now. > > > > Signed-off-by: Fenghua Yu > > --- > > arch/x86/kernel/head64.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > > index e1cb611..1ccbaf1 100644 > > --- a/arch/x86/kernel/head64.c > > +++ b/arch/x86/kernel/head64.c > > @@ -26,6 +26,7 @@ > > #include > > #include > > #include > > +#include > > > > /* > > * Manage page tables very early on. > > @@ -179,6 +180,11 @@ void __init x86_64_start_kernel(char * > real_mode_data) > > } > > load_idt((const struct desc_ptr *)_descr); > > > > + /* > > +* Load microcode early on BSP. > > +*/ > > + load_ucode_bsp(__va(real_mode_data)); > > + > > copy_bootdata(__va(real_mode_data)); > > can you make load_ucode_bsp take boot_param directly instead of > real_mode_data. ? > > could be > > > copy_bootdata(__va(real_mode_data)); > + > +/* Load microcode early on BSP. */ > + load_ucode_bsp(_params); > + > > because copy_bootdata, already copy boot_params... > > Thanks > > Yinghai That's right. Will fix this. Thanks. -Fenghua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/18] sched: consider runnable load average in move_tasks
On Wed, 12 Dec 2012 14:26:44 +0800, Alex Shi wrote:
> On 12/12/2012 12:41 PM, Preeti U Murthy wrote:
>> Also why can't p->se.load_avg_contrib be used directly? as a return
>> value for task_h_load_avg? since this is already updated in
>> update_task_entity_contrib and update_group_entity_contrib.
>
> No, only non task entity goes to update_group_entity_contrib. not task
> entity.
???
But task entity goes to __update_task_entity_contrib()?
/* Compute the current contribution to load_avg by se, return any delta */
static long __update_entity_load_avg_contrib(struct sched_entity *se)
{
long old_contrib = se->avg.load_avg_contrib;
if (entity_is_task(se)) {
__update_task_entity_contrib(se);
} else {
__update_tg_runnable_avg(>avg, group_cfs_rq(se));
__update_group_entity_contrib(se);
}
return se->avg.load_avg_contrib - old_contrib;
}
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ata: don't wait on resume
When resuming an ata port, do not wait for the function ata_port_request_pm to
return. The reasoning behing this is that we can resume the device much faster
if we do not wait for ata ports connected to spinning disks to resume.
A small change is made in ata_port_request_pm to make it return 0 when we do not
wait. Previously, the function just returned an uninitialized variable if it did
not wait.
The pm runtime status of the ata port is set to active (even though is has not
fully resumed yet).
Signed-off-by: Derek Basehore
Conflicts:
drivers/ata/libata-core.c
---
drivers/ata/libata-core.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9e8b99a..c700b79 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5279,7 +5279,7 @@ bool ata_link_offline(struct ata_link *link)
#ifdef CONFIG_PM
static int ata_port_request_pm(struct ata_port *ap, pm_message_t mesg,
unsigned int action, unsigned int ehi_flags,
- int *async)
+ int *async, int wait)
{
struct ata_link *link;
unsigned long flags;
@@ -5289,9 +5289,12 @@ static int ata_port_request_pm(struct ata_port *ap,
pm_message_t mesg,
* progress. Wait for PM_PENDING to clear.
*/
if (ap->pflags & ATA_PFLAG_PM_PENDING) {
- if (async) {
- *async = -EAGAIN;
- return 0;
+ if (!wait) {
+ if (async) {
+ *async = -EAGAIN;
+ return 0;
+ }
+ return -EAGAIN;
}
ata_port_wait_eh(ap);
WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
@@ -5303,7 +5306,7 @@ static int ata_port_request_pm(struct ata_port *ap,
pm_message_t mesg,
ap->pm_mesg = mesg;
if (async)
ap->pm_result = async;
- else
+ else if (wait)
ap->pm_result =
ap->pflags |= ATA_PFLAG_PM_PENDING;
@@ -5317,7 +5320,7 @@ static int ata_port_request_pm(struct ata_port *ap,
pm_message_t mesg,
spin_unlock_irqrestore(ap->lock, flags);
/* wait and check result */
- if (!async) {
+ if (wait) {
ata_port_wait_eh(ap);
WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
}
@@ -5341,7 +5344,8 @@ static int __ata_port_suspend_common(struct ata_port *ap,
pm_message_t mesg, int
if (mesg.event == PM_EVENT_SUSPEND)
ehi_flags |= ATA_EHI_NO_AUTOPSY | ATA_EHI_NO_RECOVERY;
- rc = ata_port_request_pm(ap, mesg, 0, ehi_flags, async);
+ rc = ata_port_request_pm(ap, mesg, 0, ehi_flags, async,
+ async == NULL ? 1 : 0);
return rc;
}
@@ -5381,7 +5385,8 @@ static int __ata_port_resume_common(struct ata_port *ap,
int *async)
int rc;
rc = ata_port_request_pm(ap, PMSG_ON, ATA_EH_RESET,
- ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, async);
+ ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, async,
+ async == NULL ? 1 : 0);
return rc;
}
@@ -5394,9 +5399,11 @@ static int ata_port_resume_common(struct device *dev)
static int ata_port_resume(struct device *dev)
{
+ struct ata_port *ap = to_ata_port(dev);
int rc;
- rc = ata_port_resume_common(dev);
+ rc = ata_port_request_pm(ap, PMSG_ON, ATA_EH_RESET,
+ ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, NULL, 0);
if (!rc) {
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] don't wait on disk to start on resume
We no longer wait for the disk to spin up in sd_resume. It now enters the
request to spinup the disk into the elevator and returns.
A function is scheduled under the scsi_sd_probe_domain to wait for the command
to spinup the disk to complete. This function then checks for errors and cleans
up after the sd resume function.
This allows system resume to complete much faster on systems with an HDD since
spinning up the disk is a significant portion of resume time.
Signed-off-by: Derek Basehore
---
drivers/scsi/sd.c | 106 +---
drivers/scsi/sd.h |9
2 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 7992635..2fe051f 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3045,6 +3045,7 @@ static void sd_shutdown(struct device *dev)
if (!sdkp)
return; /* this can happen */
+ async_synchronize_full_domain(_sd_probe_domain);
if (pm_runtime_suspended(dev))
goto exit;
@@ -3070,6 +3071,7 @@ static int sd_suspend(struct device *dev)
if (!sdkp)
return 0; /* this can happen */
+ async_synchronize_full_domain(_sd_probe_domain);
if (sdkp->WCE) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
ret = sd_sync_cache(sdkp);
@@ -3087,20 +3089,110 @@ done:
return ret;
}
+/*
+ * Callback function for when the request that starts the disk completes.
Passed
+ * into blk_execute_rq_nowait in sd_resume.
+ */
+static void sd_end_start_rq(struct request *rq, int error)
+{
+ struct completion *waiting = rq->end_io_data;
+
+ rq->end_io_data = NULL;
+ /*
+* Set the end_io_data to NULL before calling complete. This (with
+* sd_resume async) ensures that it is set to NULL before we call
+* blk_put_request.
+*/
+ complete(waiting);
+}
+
+/*
+ * Asynchronous part of sd_resume. This is separate from sd_end_start_rq since
+ * we need to block on resume for suspend and shutdown. We already do this by
+ * synchronizing on the scsi_sd_probe_domain, so use that.
+ */
+static void sd_resume_async(void *data, async_cookie_t cookie)
+{
+ struct scsi_sense_hdr sshdr;
+ struct resume_async_struct *resume = data;
+ struct scsi_disk *sdkp = resume->sdkp;
+ struct request *req = resume->req;
+
+ wait_for_completion(>wait);
+
+ if (req->errors) {
+ scsi_normalize_sense(resume->sense,
+SCSI_SENSE_BUFFERSIZE,
+);
+ sd_printk(KERN_WARNING, sdkp, "START_STOP FAILED\n");
+ sd_print_result(sdkp, req->errors);
+ if (driver_byte(req->errors) & DRIVER_SENSE)
+ sd_print_sense_hdr(sdkp, );
+ }
+ kfree(resume);
+ scsi_disk_put(sdkp);
+ blk_put_request(req);
+}
+
+/*
+ * This does not wait for the disk to spin up. This function enters the request
+ * to spinup the disk and schedules a function, sd_resume_async, that waits for
+ * that request to complete.
+ */
static int sd_resume(struct device *dev)
{
struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
- int ret = 0;
+ struct scsi_device *sdp = sdkp->device;
+ struct resume_async_struct *resume = NULL;
+ struct request *req;
+ unsigned char cmd[6] = { START_STOP }; /* START_VALID */
- if (!sdkp->device->manage_start_stop)
- goto done;
+ if (!sdkp->device->manage_start_stop) {
+ scsi_disk_put(sdkp);
+ return 0;
+ }
sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
- ret = sd_start_stop_device(sdkp, 1);
-done:
- scsi_disk_put(sdkp);
- return ret;
+ cmd[4] |= 1;/* START */
+
+ if (sdp->start_stop_pwr_cond)
+ cmd[4] |= 1 << 4; /* Active */
+
+ if (!scsi_device_online(sdp))
+ return -ENODEV;
+
+ resume = kzalloc(sizeof(struct resume_async_struct), GFP_NOIO);
+ if (!resume)
+ return DRIVER_ERROR << 24;
+
+ req = blk_get_request(sdp->request_queue, 0, __GFP_WAIT);
+ if (!req)
+ return DRIVER_ERROR << 24;
+
+ resume->req = req;
+ resume->sdkp = sdkp;
+ init_completion(>wait);
+
+ req->cmd_len = COMMAND_SIZE(cmd[0]);
+ memcpy(req->cmd, cmd, req->cmd_len);
+ req->sense = resume->sense;
+ req->sense_len = 0;
+ req->retries = SD_MAX_RETRIES;
+ req->timeout = SD_TIMEOUT;
+ req->cmd_type = REQ_TYPE_BLOCK_PC;
+ req->cmd_flags |= REQ_QUIET | REQ_PREEMPT;
+ req->end_io_data = >wait;
+
+ async_schedule_domain(sd_resume_async, resume, _sd_probe_domain);
+ /*
+* don't wait here for the disk to spin up, since we can resume faster
+* if we don't. Cleanup
Re: [PATCH 07/18] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On Thu, 13 Dec 2012 16:45:44 +0800, Alex Shi wrote:
> On 12/12/2012 11:57 AM, Preeti U Murthy wrote:
>> Hi Alex,
>> On 12/10/2012 01:52 PM, Alex Shi wrote:
>>> They are the base values in load balance, update them with rq runnable
>>> load average, then the load balance will consider runnable load avg
>>> naturally.
>>>
>
> updated with UP config fix:
>
>
> ==
>> From d271c93b40411660dd0e54d99946367c87002cc8 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Sat, 17 Nov 2012 13:56:11 +0800
> Subject: [PATCH 07/18] sched: compute runnable load avg in cpu_load and
> cpu_avg_load_per_task
>
> They are the base values in load balance, update them with rq runnable
> load average, then the load balance will consider runnable load avg
> naturally.
>
> Signed-off-by: Alex Shi
> ---
> kernel/sched/core.c | 8 ++--
> kernel/sched/fair.c | 4 ++--
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 96fa5f1..d306a84 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2487,7 +2487,7 @@ static void __update_cpu_load(struct rq *this_rq,
> unsigned long this_load,
> void update_idle_cpu_load(struct rq *this_rq)
> {
> unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
> - unsigned long load = this_rq->load.weight;
> + unsigned long load = (unsigned long)this_rq->cfs.runnable_load_avg;
So shouldn't this line be guarded with CONFIG_SMP too?
Thanks,
Namhyung
> unsigned long pending_updates;
>
> /*
> @@ -2537,8 +2537,12 @@ static void update_cpu_load_active(struct rq *this_rq)
>* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
>*/
> this_rq->last_load_update_tick = jiffies;
> - __update_cpu_load(this_rq, this_rq->load.weight, 1);
>
> +#ifdef CONFIG_SMP
> + __update_cpu_load(this_rq, this_rq->cfs.runnable_load_avg, 1);
> +#else
> + __update_cpu_load(this_rq, this_rq->load.weight, 1);
> +#endif
> calc_load_account_active(this_rq);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARC: provide optimal __get_user_fn()
On Tuesday 20 November 2012 09:21 PM, Arnd Bergmann wrote: > On Tuesday 20 November 2012, vineet.gup...@synopsys.com wrote: >> From: Vineet Gupta >> >> Signed-off-by: Vineet Gupta > > Yes, this looks good to me. > > Acked-by: Arnd Bergmann > Can you please also ACK the asm-generic bits of this series [PATCH 1/2] Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/18] sched: set initial load avg of new forked task as its load weight
On Mon, 10 Dec 2012 16:22:22 +0800, Alex Shi wrote:
> New task has no runnable sum at its first runnable time, that make
> burst forking just select few idle cpus to put tasks.
> Set initial load avg of new forked task as its load weight to resolve
> this issue.
>
> Signed-off-by: Alex Shi
> ---
> include/linux/sched.h |1 +
> kernel/sched/core.c |2 +-
> kernel/sched/fair.c | 13 +++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5dafac3..093f9cd 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1058,6 +1058,7 @@ struct sched_domain;
> #else
> #define ENQUEUE_WAKING 0
> #endif
> +#define ENQUEUE_NEWTASK 8
>
> #define DEQUEUE_SLEEP1
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e6533e1..96fa5f1 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1648,7 +1648,7 @@ void wake_up_new_task(struct task_struct *p)
> #endif
>
> rq = __task_rq_lock(p);
> - activate_task(rq, p, 0);
> + activate_task(rq, p, ENQUEUE_NEWTASK);
> p->on_rq = 1;
> trace_sched_wakeup_new(p, true);
> check_preempt_curr(rq, p, WF_FORK);
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 1faf89f..61c8d24 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1277,8 +1277,9 @@ static inline void update_rq_runnable_avg(struct rq
> *rq, int runnable)
> /* Add the load generated by se into cfs_rq's child load-average */
> static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq,
> struct sched_entity *se,
> - int wakeup)
> + int flags)
> {
> + int wakeup = flags & ENQUEUE_WAKEUP;
> /*
>* We track migrations using entity decay_count <= 0, on a wake-up
>* migration we use a negative decay count to track the remote decays
> @@ -1312,6 +1313,12 @@ static inline void enqueue_entity_load_avg(struct
> cfs_rq *cfs_rq,
> update_entity_load_avg(se, 0);
> }
>
> + /*
> + * set the initial load avg of new task same as its load
> + * in order to avoid brust fork make few cpu too heavier
> + */
> + if (flags & ENQUEUE_NEWTASK)
> + se->avg.load_avg_contrib = se->load.weight;
> cfs_rq->runnable_load_avg += se->avg.load_avg_contrib;
> /* we force update consideration on load-balancer moves */
> update_cfs_rq_blocked_load(cfs_rq, !wakeup);
> @@ -1476,7 +1483,8 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *se, int flags)
>*/
> update_curr(cfs_rq);
> account_entity_enqueue(cfs_rq, se);
> - enqueue_entity_load_avg(cfs_rq, se, flags & ENQUEUE_WAKEUP);
> + enqueue_entity_load_avg(cfs_rq, se, flags &
> + (ENQUEUE_WAKEUP | ENQUEUE_NEWTASK));
It seems that just passing 'flags' is enough.
>
> if (flags & ENQUEUE_WAKEUP) {
> place_entity(cfs_rq, se, 0);
> @@ -2586,6 +2594,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p,
> int flags)
> cfs_rq->h_nr_running++;
>
> flags = ENQUEUE_WAKEUP;
> + flags &= ~ENQUEUE_NEWTASK;
Why is this needed?
Thanks,
Namhyung
> }
>
> for_each_sched_entity(se) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] sched: select_task_rq_fair clean up
Hi,
On Tue, 11 Dec 2012 12:00:55 +0530, Preeti U. Murthy wrote:
> On 12/11/2012 10:58 AM, Alex Shi wrote:
>> On 12/11/2012 12:23 PM, Preeti U Murthy wrote:
>>> Hi Alex,
>>>
>>> On 12/10/2012 01:52 PM, Alex Shi wrote:
It is impossible to miss a task allowed cpu in a eligible group.
>>>
>>> The one thing I am concerned with here is if there is a possibility of
>>> the task changing its tsk_cpus_allowed() while this code is running.
>>>
>>> i.e find_idlest_group() finds an idle group,then the tsk_cpus_allowed()
>>> for the task changes,perhaps by the user himself,which might not include
>>> the cpus in the idle group.After this find_idlest_cpu() is called.I mean
>>> a race condition in short.Then we might not have an eligible cpu in that
>>> group right?
>>
>> your worry make sense, but the code handle the situation, in
>> select_task_rq(), it will check the cpu allowed again. if the answer is
>> no, it will fallback to old cpu.
>>>
And since find_idlest_group only return a different group which
excludes old cpu, it's also imporissible to find a new cpu same as old
cpu.
>
> I doubt this will work correctly.Consider the following situation:sched
> domain begins with sd that encloses both socket1 and socket2
>
> cpu0 cpu1 | cpu2 cpu3
> ---|-
> socket1 | socket2
>
> old cpu = cpu1
>
> Iteration1:
> 1.find_idlest_group() returns socket2 to be idlest.
> 2.task changes tsk_allowed_cpus to 0,1
> 3.find_idlest_cpu() returns cpu2
AFAIK The tsk->cpus_allowed cannot be changed during the operation since
it's protected by tsk->pi_lock. I can see the following comment:
kernel/sched/core.c:
/*
* The caller (fork, wakeup) owns p->pi_lock, ->cpus_allowed is stable.
*/
static inline
int select_task_rq(struct task_struct *p, int sd_flags, int wake_flags)
{
int cpu = p->sched_class->select_task_rq(p, sd_flags, wake_flags);
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: implement flags parameters for cyclic transfer
On Thursday 20 December 2012 10:16 PM, Stephen Warren wrote: On 12/19/2012 11:11 PM, Laxman Dewangan wrote: On Wednesday 19 December 2012 10:32 PM, Stephen Warren wrote: On 12/19/2012 06:40 AM, Laxman Dewangan wrote: The flag parameter is added in the cyclic transfer request. Use the flag option of: - DMA_PREP_INTERRUPT for enabling interrupt. - DMA_CTRL_ACK for deciding whether ack is requred or not for descriptor. Do the relevant drivers that use Tegra's DMA engine already set flags correctly, so that this change won't cause any regressions? Currently, the sound soc driver uses the cyclic mode of dma transfer and it has already enable the proper flags. This was done recently after adding flags in cyclic api. Also, there was bug in our dma driver for not setting DMA_CTRL_ACK by default for cyclic case. This will fix the issue. OK. I assume "This was done recently after adding flags in cyclic api." was a patch that went into 3.8? So, this patch is a bug-fix that should be included in 3.8 then? I can see this in Linux 3.7 tag. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=history;f=drivers/dma/tegra20-apb-dma.c;h=528c62dd4b00e1b52928ff66f3a54e7ae206680f;hb=29594404d7fe73cd80eaa4ee8c43dcc53970c60e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: tegra: dts: add aliases and DMA requestor for serial controller
On Thursday 20 December 2012 10:33 PM, Stephen Warren wrote: On 12/19/2012 11:15 PM, Laxman Dewangan wrote: On Wednesday 19 December 2012 10:30 PM, Stephen Warren wrote: On 12/18/2012 11:31 PM, Laxman Dewangan wrote: Add APB DMA requestor and serial aliases for serial controller. There will be two serial driver i.e. 8250 based simple serial driver and APB DMA based serial driver for higher baudrate and performace. The simple serial driver get enabled with compatible nvidia,tegra20-uart and APB DMA based driver will get enabled with compatible nvidia,tegra20-hsuart. This patch seems to do two things: 1) Add a comment describing how to select the basic or DMA-based driver. I can see why this is useful. 2) Add aliases for the serial ports. I have no idea why this is useful. Serial aliases are added because we want to get the port number like /dev/ttyTHS0, /d/ttyTHS2 etc. The uarta should be /dev/ttyTHS0 and uartc should be /dev/ttyTHS2. The port number can be found using aliases and of_alias_get_id() in driver file: port_number = of_alias_get_id(np, "serial"); Oh, I see. I guess the aliases make sense then. But, wouldn't you only add aliases for the specific UARTs that are in use on a particular board (so put them in tegraNN-board.dts) rather than all UARTs on Tegra (i.e. the current patch which puts them into tegraNN.dtsi)? I like to have this in tegraN N.dtsi file becasue: - This policy is not going to change the board to board. For high speed driver the uarta will be ttyTHS0 and uartb ttyTHS1. - In board file I will only enable driver and make compatible, not worry about the making aliases. This approach will simplify the instantiation. This will also avoid confusion like the aliases get added or not when we create board dts file. This will be on same line we have with board files where pdev->id is fixed for all board in common place i.e. device.c which decide the port-number. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] f2fs: add MAINTAINERS entry
This patch adds myself to MAINTAINERS entry for the f2fs file system. Signed-off-by: Jaegeuk Kim --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9386a63..f15d168 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3204,6 +3204,16 @@ F: Documentation/filesystems/caching/ F: fs/fscache/ F: include/linux/fscache*.h +F2FS FILE SYSTEM +M: Jaegeuk Kim +L: linux-f2fs-de...@lists.sourceforge.net +W: http://en.wikipedia.org/wiki/F2FS +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git +S: Maintained +F: Documentation/filesystems/f2fs.txt +F: fs/f2fs/ +F: include/linux/f2fs_fs.h + FUJITSU FR-V (FRV) PORT M: David Howells S: Maintained -- 1.8.0.1.250.gb7973fb -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 09/11] x86/head64.c: Early update ucode in 64-bit
On Thu, Dec 20, 2012 at 11:48 AM, Fenghua Yu wrote: > From: Fenghua Yu > > This updates ucode on BSP in 64-bit mode. Paging and virtual address are > working now. > > Signed-off-by: Fenghua Yu > --- > arch/x86/kernel/head64.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > index e1cb611..1ccbaf1 100644 > --- a/arch/x86/kernel/head64.c > +++ b/arch/x86/kernel/head64.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > /* > * Manage page tables very early on. > @@ -179,6 +180,11 @@ void __init x86_64_start_kernel(char * real_mode_data) > } > load_idt((const struct desc_ptr *)_descr); > > + /* > +* Load microcode early on BSP. > +*/ > + load_ucode_bsp(__va(real_mode_data)); > + > copy_bootdata(__va(real_mode_data)); can you make load_ucode_bsp take boot_param directly instead of real_mode_data. ? could be copy_bootdata(__va(real_mode_data)); + +/* Load microcode early on BSP. */ + load_ucode_bsp(_params); + because copy_bootdata, already copy boot_params... Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] notification tree changes for 3.8
On Thu, Dec 20, 2012 at 6:49 PM, Eric Paris wrote: > > It is a locking change, but if anything goes wrong, at least I've got > time without other work commitments over the next 2 weeks to fix them. That doesn't much help. Because realistically, very few people will be *testing* over the next two weeks. Grr. Ok, so I'll pull, but dammit, this kind of crap has got to stop. There's *no* reason to start rebasing when the merge window opens, and then leave it to the last day. Seriously. This bugs the hell out of me. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/16] ACPI: Rework ACPI namespace scanning for devices
On Thu, Dec 20, 2012 at 4:09 PM, Rafael J. Wysocki wrote: > On Wednesday, December 19, 2012 06:06:57 PM Yinghai Lu wrote: >> On Wed, Dec 19, 2012 at 5:45 PM, Rafael J. Wysocki wrote: >> >> great!, the .bind and .unbind go away. >> >> > >> > The patches are on top of my master branch and I'm going to rebase them >> > when >> > v3.8-rc1 is out. >> >> > >> > There is a git tree you can pull them from at: >> > >> > http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=summary >> > acpi-scan-temp-new >> > >> > It's v3.7 with my master branch merged and the new patches on top. >> >> >> can you make it base to today's Linus tree ? > > Sure. Rebased and pushed out: > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > acpi-scan-next > Thanks. I rebased pci-root-bus-hotplug patchset on top it, and it works well. So Acked-by: Yinghai Lu for the four new ones in your acpi_scan_next branch. i put the updated patches in git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-3.9 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: ipv4: route: fixed a coding style issues net: ipv4: tcp: fixed a coding style issues
From: Eric Dumazet Date: Thu, 20 Dec 2012 07:23:59 -0800 > Such "coding style" patches are a real pain when trying to fix bugs, > especially dealing with stable/old kernels. Totally agreed, and I refuse to apply such patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: ipv4: route: fix coding style issues net: ipv4: tcp: fix coding style issues
From: Stefan Hasko Date: Thu, 20 Dec 2012 15:28:05 +0100 > Fix a coding style issues. > > Signed-off-by: Stefan Hasko Again, I am absolutely not applying a whole-sale coding style patch to this file. Do not submit this patch again, regardless of what other feedback you might have gotten. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: ipv4: route: fixed a coding style issues net: ipv4: tcp: fixed a coding style issues
I'm definitely not applying this, sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: linux-next: manual merge of the arm-soc tree with the pinctrl tree
Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got conflicts in
> drivers/pinctrl/pinctrl-exynos5440.c and
> drivers/pinctrl/pinctrl-samsung.c between commit e5b4c9d4ab55 ("pinctrl:
> exynos5440: Fix compile error in pinctrl-exynos5440/samsung.c") from the
> pinctrl tree and commit d5fd5da290ce ("pinctrl: exynos5440/samsung:
> Staticize pcfgs") from the arm-soc tree.
>
Oops, the commit d5fd5da290ce already sent to Linus Torvalds via arm-soc
tree today. In addition, I applied with Linus Walleij's ack ;-)
Linus Walleij, please drop the patch in your tree. Sorry I didn't notify
about that when I got the patch from Choi.
Thanks.
- Kukjin
> The former is a superset of the latter, so I used that (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] stack and heap are executable on x86_64
Wtf... Kees Cook wrote: >On Thu, Dec 20, 2012 at 7:00 PM, Kees Cook >wrote: >> While trying to fix test_nx, I discovered that it looks like stack >and >> heap are executable again (at least on x86_64). :( I tried to bisect > >Btw, this ends up looking like this on v3.4: > >[2.486223] test_nx: Testing NX protection ... >[2.487468] test_nx: calling 88001dd57e45 (0xC3) >[2.488766] test_nx: stack is executable >[2.489802] test_nx: calling 88001e2c7580 (0xC3) >[2.491106] test_nx: heap is executable >[2.492086] test_nx: calling 81803c80 (0xC3) >[2.493201] test_nx: calling a0002220 (0xC3) >[2.493843] test_nx: calling a0001224 (0xC3) >[2.494549] test_nx: Done testing. > >-Kees > >-- >Kees Cook >Chrome OS Security -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 21
Hi all, Changes since 20121220: Lots of conflicts are migrating between trees. The infiniband tree lost its build failure. The arm-soc tree gained a conflict against the pinctrl tree. The signal tree gained conflicts against Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 213 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (810a485 Merge branch 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild) Merging fixes/master (4458315 ARM: OMAP: fix build error in arch/arm/mach-omap2/timer.c) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (e6ee4b2 ARM: 7607/1: realview: fix private peripheral memory base for EB rev. B boards) Merging m68k-current/for-linus (5fec45a m68k/sun3: Fix instruction faults) Merging powerpc-merge/merge (e716e01 powerpc/eeh: Do not invalidate PE properly) Merging sparc/master (f01af9f Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (f01af9f Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging sound-current/for-linus (d846b17 ALSA: hda - Fix build without CONFIG_PM) Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots unless port supports hotplug) Merging wireless/master (009b969 wireless: fix Atheros drivers compilation) Merging driver-core.current/driver-core-linus (1800098 ARM: OMAP: Fix build breakage due to missing include in i2c.c) Merging tty.current/tty-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging usb.current/usb-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging staging.current/staging-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging char-misc.current/char-misc-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging input-current/for-linus (022573c Merge branch 'next' into for-linus) Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device tree binding for ERA information.) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in hspi_probe().) Merging gpio-current/gpio/merge (bc1008c gpio/mvebu-gpio: Make mvebu-gpio depend on OF_CONFIG) Merging rr-fixes/fixes (f3537f9 ASN.1: Fix an indefinite length skip error) Merging asm-generic/master (fb9de7e xte
Re: [PATCH 4/5] net: sfc: fix return value check in efx_ptp_probe_channel().
On Wed, 2012-12-12 at 00:15 -0500, David Miller wrote: > From: Cyril Roelandt > Date: Wed, 12 Dec 2012 01:24:53 +0100 > > > The ptp_clock_register() returns ERR_PTR() and never returns NULL. Replace > > the > > NULL check by a call to IS_ERR(). > > > > Signed-off-by: Cyril Roelandt > > I'll let Ben queue this up. > > Probably he'll want to avoid potentially leaving an ERR_PTR > in ptp->phc_clock even if, with this fix, that would be > harmless. Sorry for the delay in looking at this. This change is fine, as the entire structure *ptp will be freed on the failure path. I'm now on vacation until the new year. Cyril, please re-send your patch with the addition of: Acked-by: Ben Hutchings so it will show up on 'patchwork' again and David can apply it from there. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] stack and heap are executable on x86_64
On Thu, Dec 20, 2012 at 7:00 PM, Kees Cook wrote: > While trying to fix test_nx, I discovered that it looks like stack and > heap are executable again (at least on x86_64). :( I tried to bisect Btw, this ends up looking like this on v3.4: [2.486223] test_nx: Testing NX protection ... [2.487468] test_nx: calling 88001dd57e45 (0xC3) [2.488766] test_nx: stack is executable [2.489802] test_nx: calling 88001e2c7580 (0xC3) [2.491106] test_nx: heap is executable [2.492086] test_nx: calling 81803c80 (0xC3) [2.493201] test_nx: calling a0002220 (0xC3) [2.493843] test_nx: calling a0001224 (0xC3) [2.494549] test_nx: Done testing. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -tip 2/4] tracing: replace static old_tracer with strcmp
On Wed, 2012-12-19 at 16:02 +0900, Hiraku Toyooka wrote:
> Currently, read functions for trace buffer use static "old_tracer"
> for detecting changes of current tracer. This is because we can
> assume that these functions are used from only one file ("trace").
>
> But we are adding snapshot feature for ftrace, then those functions
> are called from two files. So we remove all static "old_tracer", and
> replace those with string comparison between current and previous
> tracers.
I reworded what you wrote:
---
Currently the trace buffer read functions use a static variable
"old_tracer" for detecting if the current tracer changes. This was
suitable for a single trace file ("trace"), but to add a snapshot
feature that will use the same function for its file, a check against
a static variable is not sufficient.
To use the output functions for two different files, instead of storing
the current tracer in a static variable, as the trace iterator
descriptor
contains a pointer to the original current tracer's name, that pointer
can now be used to check if the current tracer has changed between
different reads of the trace file.
---
And I also realized a more efficient approach.
>
> Signed-off-by: Hiraku Toyooka
> Cc: Steven Rostedt
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> Cc: linux-kernel@vger.kernel.org
> ---
> kernel/trace/trace.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index a8ce008..8d05a44 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1948,7 +1948,6 @@ void tracing_iter_reset(struct trace_iterator *iter,
> int cpu)
> static void *s_start(struct seq_file *m, loff_t *pos)
> {
> struct trace_iterator *iter = m->private;
> - static struct tracer *old_tracer;
> int cpu_file = iter->cpu_file;
> void *p = NULL;
> loff_t l = 0;
> @@ -1956,10 +1955,9 @@ static void *s_start(struct seq_file *m, loff_t *pos)
>
> /* copy the tracer to avoid using a global lock all around */
> mutex_lock(_types_lock);
> - if (unlikely(old_tracer != current_trace && current_trace)) {
> - old_tracer = current_trace;
> + if (unlikely(current_trace &&
> + strcmp(iter->trace->name, current_trace->name) != 0))
> *iter->trace = *current_trace;
As iter->trace is a copy of current_trace, it points to everything that
the current_trace pointed to. As the current_trace->name is a pointer to
a const char string that never changes, we don't need to do the strcmp()
you can simply do a direct comparison:
if (unlikely(current_trace && iter->trace->name !=
current_trace->name)) {
I would add a comment about that too:
/*
* iter->trace is a copy of current_trace, the pointer to the
* name may be used instead of a strcmp(), as iter->trace->name
* will point to the same string as current_trace->name.
*/
-- Steve
> - }
> mutex_unlock(_types_lock);
>
> atomic_inc(_record_cmdline_disabled);
> @@ -3481,7 +3479,6 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,
> size_t cnt, loff_t *ppos)
> {
> struct trace_iterator *iter = filp->private_data;
> - static struct tracer *old_tracer;
> ssize_t sret;
>
> /* return any leftover data */
> @@ -3493,10 +3490,9 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,
>
> /* copy the tracer to avoid using a global lock all around */
> mutex_lock(_types_lock);
> - if (unlikely(old_tracer != current_trace && current_trace)) {
> - old_tracer = current_trace;
> + if (unlikely(current_trace &&
> + strcmp(iter->trace->name, current_trace->name) != 0))
> *iter->trace = *current_trace;
> - }
> mutex_unlock(_types_lock);
>
> /*
> @@ -3652,7 +3648,6 @@ static ssize_t tracing_splice_read_pipe(struct file
> *filp,
> .ops= _pipe_buf_ops,
> .spd_release= tracing_spd_release_pipe,
> };
> - static struct tracer *old_tracer;
> ssize_t ret;
> size_t rem;
> unsigned int i;
> @@ -3662,10 +3657,9 @@ static ssize_t tracing_splice_read_pipe(struct file
> *filp,
>
> /* copy the tracer to avoid using a global lock all around */
> mutex_lock(_types_lock);
> - if (unlikely(old_tracer != current_trace && current_trace)) {
> - old_tracer = current_trace;
> + if (unlikely(current_trace &&
> + strcmp(iter->trace->name, current_trace->name) != 0))
> *iter->trace = *current_trace;
> - }
> mutex_unlock(_types_lock);
>
> mutex_lock(>mutex);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [patch 2/7] mm: vmscan: save work scanning (almost) empty LRU lists
On Wed, Dec 19, 2012 at 03:59:01PM -0800, Andrew Morton wrote: > On Mon, 17 Dec 2012 13:12:32 -0500 > Johannes Weiner wrote: > > > In certain cases (kswapd reclaim, memcg target reclaim), a fixed > > minimum amount of pages is scanned from the LRU lists on each > > iteration, to make progress. > > > > Do not make this minimum bigger than the respective LRU list size, > > however, and save some busy work trying to isolate and reclaim pages > > that are not there. > > > > Empty LRU lists are quite common with memory cgroups in NUMA > > environments because there exists a set of LRU lists for each zone for > > each memory cgroup, while the memory of a single cgroup is expected to > > stay on just one node. The number of expected empty LRU lists is thus > > > > memcgs * (nodes - 1) * lru types > > > > Each attempt to reclaim from an empty LRU list does expensive size > > comparisons between lists, acquires the zone's lru lock etc. Avoid > > that. > > > > ... > > > > -#define SWAP_CLUSTER_MAX 32 > > +#define SWAP_CLUSTER_MAX 32UL > > You made me review the effects of this change. It looks OK. A few > cleanups are possible, please review. > > I wonder what happens in __setup_per_zone_wmarks() if we set > SWAP_CLUSTER_MAX greater than 128. In the current clamp() implementation max overrides min, so... BUILD_BUG_ON()? Probably unnecessary, it seems like a rather arbitrary range to begin with. > From: Andrew Morton > Subject: mm/page_alloc.c:__setup_per_zone_wmarks: make min_pages unsigned long > > `int' is an inappropriate type for a number-of-pages counter. > > While we're there, use the clamp() macro. > > Cc: Johannes Weiner > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Hugh Dickins > Cc: Satoru Moriya > Cc: Simon Jeons > Signed-off-by: Andrew Morton Acked-by: Johannes Weiner > From: Andrew Morton > Subject: mm/vmscan.c:shrink_lruvec(): switch to min() > > "mm: vmscan: save work scanning (almost) empty LRU lists" made > SWAP_CLUSTER_MAX an unsigned long. > > Cc: Johannes Weiner > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Hugh Dickins > Cc: Satoru Moriya > Cc: Simon Jeons > Signed-off-by: Andrew Morton Acked-by: Johannes Weiner > From: Andrew Morton > Subject: mm/vmscan.c:__zone_reclaim(): replace max_t() with max() > > "mm: vmscan: save work scanning (almost) empty LRU lists" made > SWAP_CLUSTER_MAX an unsigned long. > > Cc: Johannes Weiner > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Hugh Dickins > Cc: Satoru Moriya > Cc: Simon Jeons > Signed-off-by: Andrew Morton Acked-by: Johannes Weiner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] epoll: stop comparing pointers with 0 in self-test app
I don't see anything obviously wrong here...
Reviewed-By: Daniel Hazelton
On 12/20/2012 02:11 PM, Sasha Levin wrote:
Signed-off-by: Sasha Levin
---
tools/testing/selftests/epoll/test_epoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/epoll/test_epoll.c
b/tools/testing/selftests/epoll/test_epoll.c
index 4a14a7f..1034ed4 100644
--- a/tools/testing/selftests/epoll/test_epoll.c
+++ b/tools/testing/selftests/epoll/test_epoll.c
@@ -199,8 +199,8 @@ int main(int argc, char **argv)
epoll_items = malloc(n_epoll_items * sizeof(struct epoll_item_private));
- if (epoll_set < 0 || epoll_items == 0 || write_thread_data.fds == 0 ||
- read_thread_data == 0 || read_threads == 0)
+ if (epoll_set < 0 || !epoll_items || write_thread_data.fds == NULL ||
+ !read_thread_data || !read_threads)
goto error;
if (sysconf(_SC_NPROCESSORS_ONLN) < 2) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] stack and heap are executable on x86_64
This patch only works up until 706276543b699d80f546e45f8b12574e7b18d952
(v3.5), where the exception tables are made relative. Prior to that,
stock test_nx didn't work because of 84e1c6bb38eb318e456558b610396d9f1afaabf0
(v2.6.38) makes the table read-only.
While trying to fix test_nx, I discovered that it looks like stack and
heap are executable again (at least on x86_64). :( I tried to bisect
this, but ran into a lot of trouble in the x86/x86_64 merging, where
things either didn't compile or didn't boot. Regardless:
1a98fd1 bad
...
736f12b good
So it looks like it broke in 2.6.27, and no one noticed until 2.6.38 when
it wasn't possible to run the test any more, and then stayed unnoticed.
This change for pre-v3.5 creates a new exception table instead of
trying to rewrite the old one. Since the tables are now relative,
we can't actually set up an exception for things in stack and heap on
x86_64 since the distance between the address and the table's .insn is
more than INT_MAX. And if the table were moved into the stack or heap,
then the fixup couldn't point back to the module's text segment. For
v3.5 and later, I'm not sure what to do...
So, mainly two things:
- we need to fix the stack/heap markings.
- it'd be nice to get test_nx back on its feet again.
Thoughts?
-Kees
Signed-off-by: Kees Cook
---
arch/x86/kernel/test_nx.c | 107 ++---
1 file changed, 71 insertions(+), 36 deletions(-)
diff --git a/arch/x86/kernel/test_nx.c b/arch/x86/kernel/test_nx.c
index 3f92ce0..cbaa557 100644
--- a/arch/x86/kernel/test_nx.c
+++ b/arch/x86/kernel/test_nx.c
@@ -9,6 +9,9 @@
* as published by the Free Software Foundation; version 2
* of the License.
*/
+
+#define pr_fmt(fmt) "test_nx: " fmt
+
#include
#include
#include
@@ -16,6 +19,11 @@
#include
#include
+/* 0xC3 is the opcode for "ret" */
+#define INSN_RET 0xC3
+/* 0x90 is the opcode for "nop" */
+#define INSN_NOP 0x90
+
extern int rodata_test_data;
/*
@@ -34,18 +42,15 @@ extern int rodata_test_data;
* (otherwise we'd have to sort and that's just too messy)
*/
-
-
/*
* We want to set up an exception handling point on our stack,
- * which means a variable value. This function is rather dirty
- * and walks the exception table of the module, looking for a magic
- * marker and replaces it with a specific function.
+ * which means a variable value.
*/
-static void fudze_exception_table(void *marker, void *new)
+static struct exception_table_entry *original_extable;
+static struct exception_table_entry replaced_extable;
+static void fake_exception_table(void *new)
{
struct module *mod = THIS_MODULE;
- struct exception_table_entry *extable;
/*
* Note: This module has only 1 exception table entry,
@@ -54,12 +59,30 @@ static void fudze_exception_table(void *marker, void *new)
* table.
*/
if (mod->num_exentries > 1) {
- printk(KERN_ERR "test_nx: too many exception table entries!\n");
- printk(KERN_ERR "test_nx: test results are not reliable.\n");
+ pr_err("too many exception table entries!\n");
+ pr_err("test results are not reliable.\n");
return;
}
- extable = (struct exception_table_entry *)mod->extable;
- extable[0].insn = (unsigned long)new;
+ /* Save original exception table when first called. */
+ if (original_extable == NULL)
+ original_extable = mod->extable;
+ /* Replace the original exception table with a duplicate. */
+ if (mod->extable == original_extable)
+ mod->extable = _extable;
+
+ /* Record new insn address. */
+ mod->extable->insn = (unsigned long)new;
+
+ /* Record new fixup address. */
+ mod->extable->fixup = original_extable->fixup;
+}
+
+static void restore_exception_table(void)
+{
+ struct module *mod = THIS_MODULE;
+
+ if (original_extable)
+ mod->extable = original_extable;
}
@@ -82,7 +105,8 @@ static noinline int test_address(void *address)
unsigned long result;
/* Set up an exception table entry for our address */
- fudze_exception_table(_label, address);
+ fake_exception_table(address);
+ pr_info("calling %p (0x%02X)\n", address, *(unsigned char *)address);
result = 1;
asm volatile(
"foo_label:\n"
@@ -97,76 +121,87 @@ static noinline int test_address(void *address)
: [fake_code] "r" (address), [zero] "r" (0UL), "0" (result)
);
/* change the exception table back for the next round */
- fudze_exception_table(address, _label);
+ restore_exception_table();
if (result)
return -ENODEV;
return 0;
}
-static unsigned char test_data = 0xC3; /* 0xC3 is the opcode for "ret" */
+static unsigned char test_data;
+static const int module_rodata_test_data = INSN_RET;
[PATCH v4 03/11] x86/common.c: Make have_cpuid_p() a global function and load ucode or show ucode loading info on AP
From: Fenghua Yu
Remove static declaration in have_cpuid_p() to make it a global function. The
function will be called in early loading microcode.
In 64 bit, load ucode on AP in cpu_init(). In 32 bit, show ucode loading info
on AP in cpu_init().
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/processor.h | 8
arch/x86/kernel/cpu/common.c | 17 +++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 888184b..3d722fd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -190,6 +190,14 @@ extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
extern void detect_extended_topology(struct cpuinfo_x86 *c);
extern void detect_ht(struct cpuinfo_x86 *c);
+#ifdef CONFIG_X86_32
+extern int have_cpuid_p(void);
+#else
+static inline int have_cpuid_p(void)
+{
+ return 1;
+}
+#endif
static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx)
{
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9c3ab43..d814772 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -37,6 +37,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_X86_LOCAL_APIC
#include
@@ -213,7 +215,7 @@ static inline int flag_is_changeable_p(u32 flag)
}
/* Probe for the CPUID instruction */
-static int __cpuinit have_cpuid_p(void)
+int __cpuinit have_cpuid_p(void)
{
return flag_is_changeable_p(X86_EFLAGS_ID);
}
@@ -249,11 +251,6 @@ static inline int flag_is_changeable_p(u32 flag)
{
return 1;
}
-/* Probe for the CPUID instruction */
-static inline int have_cpuid_p(void)
-{
- return 1;
-}
static inline void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
{
}
@@ -1223,6 +1220,12 @@ void __cpuinit cpu_init(void)
int cpu;
int i;
+ /*
+* Load microcode on this cpu if a valid microcode is available.
+* This is early microcode loading procedure.
+*/
+ load_ucode_ap();
+
cpu = stack_smp_processor_id();
t = _cpu(init_tss, cpu);
oist = _cpu(orig_ist, cpu);
@@ -1314,6 +1317,8 @@ void __cpuinit cpu_init(void)
struct tss_struct *t = _cpu(init_tss, cpu);
struct thread_struct *thread = >thread;
+ show_ucode_info_early();
+
if (cpumask_test_and_set_cpu(cpu, cpu_initialized_mask)) {
printk(KERN_WARNING "CPU#%d already initialized!\n", cpu);
for (;;)
--
1.8.0.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 v4 02/11] x86/microcode_intel.h: Define functions and macros for early loading ucode
From: Fenghua Yu
Define some functions and macros that will be used in early loading ucode. Some
of them are moved from microcode_intel.c driver in order to be called in early
boot phase before module can be called.
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/microcode_intel.h | 85 ++
arch/x86/kernel/Makefile | 3 +
arch/x86/kernel/microcode_core.c | 7 +-
arch/x86/kernel/microcode_intel.c | 198 +
4 files changed, 122 insertions(+), 171 deletions(-)
create mode 100644 arch/x86/include/asm/microcode_intel.h
diff --git a/arch/x86/include/asm/microcode_intel.h
b/arch/x86/include/asm/microcode_intel.h
new file mode 100644
index 000..362fcc5
--- /dev/null
+++ b/arch/x86/include/asm/microcode_intel.h
@@ -0,0 +1,85 @@
+#ifndef _ASM_X86_MICROCODE_INTEL_H
+#define _ASM_X86_MICROCODE_INTEL_H
+
+#include
+
+struct microcode_header_intel {
+ unsigned inthdrver;
+ unsigned intrev;
+ unsigned intdate;
+ unsigned intsig;
+ unsigned intcksum;
+ unsigned intldrver;
+ unsigned intpf;
+ unsigned intdatasize;
+ unsigned inttotalsize;
+ unsigned intreserved[3];
+};
+
+struct microcode_intel {
+ struct microcode_header_intel hdr;
+ unsigned intbits[0];
+};
+
+/* microcode format is extended from prescott processors */
+struct extended_signature {
+ unsigned intsig;
+ unsigned intpf;
+ unsigned intcksum;
+};
+
+struct extended_sigtable {
+ unsigned intcount;
+ unsigned intcksum;
+ unsigned intreserved[3];
+ struct extended_signature sigs[0];
+};
+
+#define DEFAULT_UCODE_DATASIZE (2000)
+#define MC_HEADER_SIZE (sizeof(struct microcode_header_intel))
+#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
+#define EXT_HEADER_SIZE(sizeof(struct extended_sigtable))
+#define EXT_SIGNATURE_SIZE (sizeof(struct extended_signature))
+#define DWSIZE (sizeof(u32))
+
+#define get_totalsize(mc) \
+ (((struct microcode_intel *)mc)->hdr.totalsize ? \
+((struct microcode_intel *)mc)->hdr.totalsize : \
+DEFAULT_UCODE_TOTALSIZE)
+
+#define get_datasize(mc) \
+ (((struct microcode_intel *)mc)->hdr.datasize ? \
+((struct microcode_intel *)mc)->hdr.datasize : DEFAULT_UCODE_DATASIZE)
+
+#define sigmatch(s1, s2, p1, p2) \
+ (((s1) == (s2)) && (((p1) & (p2)) || (((p1) == 0) && ((p2) == 0
+
+#define exttable_size(et) ((et)->count * EXT_SIGNATURE_SIZE + EXT_HEADER_SIZE)
+
+extern int
+get_matching_microcode(unsigned int csig, int cpf, void *mc, int rev);
+extern int microcode_sanity_check(void *mc, int print_err);
+extern int get_matching_sig(unsigned int csig, int cpf, void *mc, int rev);
+extern int
+update_match_revision(struct microcode_header_intel *mc_header, int rev);
+
+#ifdef CONFIG_MICROCODE_INTEL_EARLY
+extern void __init load_ucode_intel_bsp(char *real_mode_data);
+extern void __cpuinit load_ucode_intel_ap(void);
+extern void show_ucode_info_early(void);
+#else
+static inline __init void load_ucode_intel_bsp(char *real_mode_data) {}
+static inline __cpuinit void load_ucode_intel_ap(void) {}
+static inline void show_ucode_info_early(void) {}
+#endif
+
+#if defined(CONFIG_MICROCODE_INTEL_EARLY) && defined(CONFIG_HOTPLUG_CPU)
+extern int save_mc_for_early(u8 *mc);
+#else
+static inline int save_mc_for_early(u8 *mc)
+{
+ return 0;
+}
+#endif
+
+#endif /* _ASM_X86_MICROCODE_INTEL_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 34e923a..052abee 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -88,6 +88,9 @@ obj-$(CONFIG_PARAVIRT_CLOCK) += pvclock.o
obj-$(CONFIG_PCSPKR_PLATFORM) += pcspeaker.o
+obj-$(CONFIG_MICROCODE_EARLY) += microcode_core_early.o
+obj-$(CONFIG_MICROCODE_INTEL_EARLY)+= microcode_intel_early.o
+obj-$(CONFIG_MICROCODE_INTEL_LIB) += microcode_intel_lib.o
microcode-y:= microcode_core.o
microcode-$(CONFIG_MICROCODE_INTEL)+= microcode_intel.o
microcode-$(CONFIG_MICROCODE_AMD) += microcode_amd.o
diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index 3a04b22..22db92b 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -364,10 +364,7 @@ static struct attribute_group mc_attr_group = {
static void microcode_fini_cpu(int cpu)
{
- struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-
microcode_ops->microcode_fini_cpu(cpu);
- uci->valid = 0;
}
static enum ucode_state microcode_resume_cpu(int cpu)
@@ -383,6 +380,10 @@ static enum ucode_state microcode_resume_cpu(int cpu)
static enum ucode_state microcode_init_cpu(int
Re: [patch 5/7] mm: vmscan: clean up get_scan_count()
On Wed, Dec 19, 2012 at 04:08:05PM -0800, Andrew Morton wrote:
> On Mon, 17 Dec 2012 13:12:35 -0500
> Johannes Weiner wrote:
>
> > Reclaim pressure balance between anon and file pages is calculated
> > through a tuple of numerators and a shared denominator.
> >
> > Exceptional cases that want to force-scan anon or file pages configure
> > the numerators and denominator such that one list is preferred, which
> > is not necessarily the most obvious way:
> >
> > fraction[0] = 1;
> > fraction[1] = 0;
> > denominator = 1;
> > goto out;
> >
> > Make this easier by making the force-scan cases explicit and use the
> > fractionals only in case they are calculated from reclaim history.
> >
> > And bring the variable declarations/definitions in order.
> >
> > ...
> >
> > + u64 fraction[2], uninitialized_var(denominator);
>
> Using uninitialized_var() puts Linus into rant mode. Unkindly, IMO:
> uninitialized_var() is documentarily useful and reduces bloat. There is
> a move afoot to replace it with
>
> int foo = 0;/* gcc */
>
> To avoid getting ranted at we can do
>
> --- a/mm/vmscan.c~mm-vmscan-clean-up-get_scan_count-fix
> +++ a/mm/vmscan.c
> @@ -1658,7 +1658,8 @@ static void get_scan_count(struct lruvec
> unsigned long *nr)
> {
> struct zone_reclaim_stat *reclaim_stat = >reclaim_stat;
> - u64 fraction[2], uninitialized_var(denominator);
> + u64 fraction[2];
> + u64 denominator = 0;
> struct zone *zone = lruvec_zone(lruvec);
> unsigned long anon_prio, file_prio;
> enum scan_balance scan_balance;
Makes sense, I guess, but then you have to delete this line from the
changelog:
"And bring the variable declarations/definitions in order."
Or change it to "partial" order or something... :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 04/11] x86/microcode_core_early.c: Define interfaces for early loading ucode
From: Fenghua Yu
Define interfaces load_ucode_bsp() and load_ucode_ap() to load ucode on BSP and
AP in early boot time. These are generic interfaces. Internally they call
vendor specific implementations.
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/microcode.h | 14 +++
arch/x86/kernel/microcode_core_early.c | 76 ++
2 files changed, 90 insertions(+)
create mode 100644 arch/x86/kernel/microcode_core_early.c
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 43d921b..01a244b 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -57,4 +57,18 @@ static inline struct microcode_ops * __init
init_amd_microcode(void)
static inline void __exit exit_amd_microcode(void) {}
#endif
+#ifdef CONFIG_MICROCODE_EARLY
+#define MAX_UCODE_COUNT 128
+extern void __init load_ucode_bsp(char *real_mode_data);
+extern __init void load_ucode_ap(void);
+extern int __init save_microcode_in_initrd(void);
+#else
+static inline void __init load_ucode_bsp(char *real_mode_data) {}
+static inline __init void load_ucode_ap(void) {}
+static inline int __init save_microcode_in_initrd(void)
+{
+ return 0;
+}
+#endif
+
#endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/kernel/microcode_core_early.c
b/arch/x86/kernel/microcode_core_early.c
new file mode 100644
index 000..ba191b5
--- /dev/null
+++ b/arch/x86/kernel/microcode_core_early.c
@@ -0,0 +1,76 @@
+/*
+ * X86 CPU microcode early update for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+
+#define QCHAR(a, b, c, d) ((a) + ((b) << 8) + ((c) << 16) + ((d) << 24))
+#define CPUID_INTEL1 QCHAR('G', 'e', 'n', 'u')
+#define CPUID_INTEL2 QCHAR('i', 'n', 'e', 'I')
+#define CPUID_INTEL3 QCHAR('n', 't', 'e', 'l')
+#define CPUID_AMD1 QCHAR('A', 'u', 't', 'h')
+#define CPUID_AMD2 QCHAR('e', 'n', 't', 'i')
+#define CPUID_AMD3 QCHAR('c', 'A', 'M', 'D')
+
+#define CPUID_IS(a, b, c, ebx, ecx, edx) \
+ (!((ebx ^ (a))|(edx ^ (b))|(ecx ^ (c
+
+/*
+ * In early loading microcode phase on BSP, boot_cpu_data is not set up yet.
+ * x86_vendor() gets vendor id for BSP.
+ *
+ * In 32 bit AP case, accessing boot_cpu_data needs linear address. To simplify
+ * coding, we still use x86_vendor() to get vendor id for AP.
+ *
+ * x86_vendor() gets vendor information directly through cpuid.
+ */
+static int __cpuinit x86_vendor(void)
+{
+ u32 eax = 0x;
+ u32 ebx, ecx = 0, edx;
+
+ if (!have_cpuid_p())
+ return X86_VENDOR_UNKNOWN;
+
+ native_cpuid(, , , );
+
+ if (CPUID_IS(CPUID_INTEL1, CPUID_INTEL2, CPUID_INTEL3, ebx, ecx, edx))
+ return X86_VENDOR_INTEL;
+
+ if (CPUID_IS(CPUID_AMD1, CPUID_AMD2, CPUID_AMD3, ebx, ecx, edx))
+ return X86_VENDOR_AMD;
+
+ return X86_VENDOR_UNKNOWN;
+}
+
+void __init load_ucode_bsp(char *real_mode_data)
+{
+ int vendor = x86_vendor();
+
+ if (vendor == X86_VENDOR_INTEL)
+ load_ucode_intel_bsp(real_mode_data);
+}
+
+void __cpuinit load_ucode_ap(void)
+{
+ int vendor = x86_vendor();
+
+ if (vendor == X86_VENDOR_INTEL)
+ load_ucode_intel_ap();
+}
--
1.8.0.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 v4 06/11] x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled()
From: Fenghua Yu
This function is called in __native_flush_tlb_global() and after
apply_microcode_early().
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/tlbflush.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 0fee48e..50a7fc0 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -20,10 +20,20 @@ static inline void __native_flush_tlb(void)
native_write_cr3(native_read_cr3());
}
+static inline void __native_flush_tlb_global_irq_disabled(void)
+{
+ unsigned long cr4;
+
+ cr4 = native_read_cr4();
+ /* clear PGE */
+ native_write_cr4(cr4 & ~X86_CR4_PGE);
+ /* write old PGE again and flush TLBs */
+ native_write_cr4(cr4);
+}
+
static inline void __native_flush_tlb_global(void)
{
unsigned long flags;
- unsigned long cr4;
/*
* Read-modify-write to CR4 - protect it from preemption and
@@ -32,11 +42,7 @@ static inline void __native_flush_tlb_global(void)
*/
raw_local_irq_save(flags);
- cr4 = native_read_cr4();
- /* clear PGE */
- native_write_cr4(cr4 & ~X86_CR4_PGE);
- /* write old PGE again and flush TLBs */
- native_write_cr4(cr4);
+ __native_flush_tlb_global_irq_disabled();
raw_local_irq_restore(flags);
}
--
1.8.0.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 v4 05/11] x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
From: Fenghua Yu
Define interfaces microcode_sanity_check() and get_matching_microcode(). They
are called both in early boot time and in microcode Intel driver.
Signed-off-by: Fenghua Yu
---
arch/x86/kernel/microcode_intel_lib.c | 174 ++
1 file changed, 174 insertions(+)
create mode 100644 arch/x86/kernel/microcode_intel_lib.c
diff --git a/arch/x86/kernel/microcode_intel_lib.c
b/arch/x86/kernel/microcode_intel_lib.c
new file mode 100644
index 000..ce69320
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_lib.c
@@ -0,0 +1,174 @@
+/*
+ * Intel CPU Microcode Update Driver for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 8.11 of Volume 3a, IA-32 Intel? Architecture
+ * Software Developer's Manual
+ * Order Number 253668 or free download from:
+ *
+ * http://developer.intel.com/Assets/PDF/manual/253668.pdf
+ *
+ * For more information, go to http://www.urbanmyth.org/microcode
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline int
+update_match_cpu(unsigned int csig, unsigned int cpf,
+unsigned int sig, unsigned int pf)
+{
+ return (!sigmatch(sig, csig, pf, cpf)) ? 0 : 1;
+}
+
+int
+update_match_revision(struct microcode_header_intel *mc_header, int rev)
+{
+ return (mc_header->rev <= rev) ? 0 : 1;
+}
+
+int microcode_sanity_check(void *mc, int print_err)
+{
+ unsigned long total_size, data_size, ext_table_size;
+ struct microcode_header_intel *mc_header = mc;
+ struct extended_sigtable *ext_header = NULL;
+ int sum, orig_sum, ext_sigcount = 0, i;
+ struct extended_signature *ext_sig;
+
+ total_size = get_totalsize(mc_header);
+ data_size = get_datasize(mc_header);
+
+ if (data_size + MC_HEADER_SIZE > total_size) {
+ if (print_err)
+ pr_err("error! Bad data size in microcode data file\n");
+ return -EINVAL;
+ }
+
+ if (mc_header->ldrver != 1 || mc_header->hdrver != 1) {
+ if (print_err)
+ pr_err("error! Unknown microcode update format\n");
+ return -EINVAL;
+ }
+ ext_table_size = total_size - (MC_HEADER_SIZE + data_size);
+ if (ext_table_size) {
+ if ((ext_table_size < EXT_HEADER_SIZE)
+|| ((ext_table_size - EXT_HEADER_SIZE) % EXT_SIGNATURE_SIZE)) {
+ if (print_err)
+ pr_err("error! Small exttable size in microcode
data file\n");
+ return -EINVAL;
+ }
+ ext_header = mc + MC_HEADER_SIZE + data_size;
+ if (ext_table_size != exttable_size(ext_header)) {
+ if (print_err)
+ pr_err("error! Bad exttable size in microcode
data file\n");
+ return -EFAULT;
+ }
+ ext_sigcount = ext_header->count;
+ }
+
+ /* check extended table checksum */
+ if (ext_table_size) {
+ int ext_table_sum = 0;
+ int *ext_tablep = (int *)ext_header;
+
+ i = ext_table_size / DWSIZE;
+ while (i--)
+ ext_table_sum += ext_tablep[i];
+ if (ext_table_sum) {
+ if (print_err)
+ pr_warn("aborting, bad extended signature table
checksum\n");
+ return -EINVAL;
+ }
+ }
+
+ /* calculate the checksum */
+ orig_sum = 0;
+ i = (MC_HEADER_SIZE + data_size) / DWSIZE;
+ while (i--)
+ orig_sum += ((int *)mc)[i];
+ if (orig_sum) {
+ if (print_err)
+ pr_err("aborting, bad checksum\n");
+ return -EINVAL;
+ }
+ if (!ext_table_size)
+ return 0;
+ /* check extended signature checksum */
+ for (i = 0; i < ext_sigcount; i++) {
+ ext_sig = (void *)ext_header + EXT_HEADER_SIZE +
+ EXT_SIGNATURE_SIZE * i;
+ sum = orig_sum
+ - (mc_header->sig + mc_header->pf + mc_header->cksum)
+ + (ext_sig->sig + ext_sig->pf + ext_sig->cksum);
+ if (sum) {
+ if (print_err)
+ pr_err("aborting, bad checksum\n");
+
[PATCH v4 09/11] x86/head64.c: Early update ucode in 64-bit
From: Fenghua Yu This updates ucode on BSP in 64-bit mode. Paging and virtual address are working now. Signed-off-by: Fenghua Yu --- arch/x86/kernel/head64.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index e1cb611..1ccbaf1 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -26,6 +26,7 @@ #include #include #include +#include /* * Manage page tables very early on. @@ -179,6 +180,11 @@ void __init x86_64_start_kernel(char * real_mode_data) } load_idt((const struct desc_ptr *)_descr); + /* +* Load microcode early on BSP. +*/ + load_ucode_bsp(__va(real_mode_data)); + copy_bootdata(__va(real_mode_data)); if (console_loglevel == 10) -- 1.8.0.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 v4 11/11] x86/Kconfig: Configurations to enable/disable the feature
From: Fenghua Yu MICROCODE_INTEL_LIB, MICROCODE_INTEL_EARLY, and MICROCODE_EARLY are three new configurations to enable or disable the feature. Signed-off-by: Fenghua Yu --- arch/x86/Kconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 97f8c5a..7f63084 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1030,6 +1030,24 @@ config MICROCODE_OLD_INTERFACE def_bool y depends on MICROCODE +config MICROCODE_INTEL_LIB + def_bool y + depends on MICROCODE_INTEL + +config MICROCODE_INTEL_EARLY + bool "Early load microcode" + depends on MICROCODE_INTEL && BLK_DEV_INITRD + default y + help + This option provides functionality to read additional microcode data + at the beginning of initrd image. The data tells kernel to load + microcode to CPU's as early as possible. No functional change if no + microcode data is glued to the initrd, therefore it's safe to say Y. + +config MICROCODE_EARLY + def_bool y + depends on MICROCODE_INTEL_EARLY + config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" ---help--- -- 1.8.0.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 v4 07/11] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
From: Fenghua Yu
Implementation of early update ucode on Intel's CPU.
load_ucode_intel_bsp() scans ucode in initrd image file which is a cpio format
ucode followed by ordinary initrd image file. The binary ucode file is stored
in kernel/x86/microcode/GenuineIntel.bin in the cpio data. All ucode
patches with the same model as BSP are saved in memory. A matching ucode patch
is updated on BSP.
load_ucode_intel_ap() reads saved ucoded patches and updates ucode on AP.
Signed-off-by: Fenghua Yu
---
arch/x86/kernel/microcode_intel_early.c | 792
1 file changed, 792 insertions(+)
create mode 100644 arch/x86/kernel/microcode_intel_early.c
diff --git a/arch/x86/kernel/microcode_intel_early.c
b/arch/x86/kernel/microcode_intel_early.c
new file mode 100644
index 000..202b103
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -0,0 +1,792 @@
+/*
+ * Intel CPU microcode early update for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+unsigned long mc_saved_in_initrd[MAX_UCODE_COUNT];
+struct mc_saved_data {
+ unsigned int mc_saved_count;
+ struct microcode_intel **mc_saved;
+} mc_saved_data;
+
+static enum ucode_state __cpuinit
+generic_load_microcode_early(struct microcode_intel **mc_saved_p,
+unsigned int mc_saved_count,
+struct ucode_cpu_info *uci)
+{
+ struct microcode_intel *ucode_ptr, *new_mc = NULL;
+ int new_rev = uci->cpu_sig.rev;
+ enum ucode_state state = UCODE_OK;
+ unsigned int mc_size;
+ struct microcode_header_intel *mc_header;
+ unsigned int csig = uci->cpu_sig.sig;
+ unsigned int cpf = uci->cpu_sig.pf;
+ int i;
+
+ for (i = 0; i < mc_saved_count; i++) {
+ ucode_ptr = mc_saved_p[i];
+
+ mc_header = (struct microcode_header_intel *)ucode_ptr;
+ mc_size = get_totalsize(mc_header);
+ if (get_matching_microcode(csig, cpf, ucode_ptr, new_rev)) {
+ new_rev = mc_header->rev;
+ new_mc = ucode_ptr;
+ }
+ }
+
+ if (!new_mc) {
+ state = UCODE_NFOUND;
+ goto out;
+ }
+
+ uci->mc = (struct microcode_intel *)new_mc;
+out:
+ return state;
+}
+
+static void __cpuinit
+microcode_pointer(struct microcode_intel **mc_saved,
+ unsigned long *mc_saved_in_initrd,
+ unsigned long initrd_start, int mc_saved_count)
+{
+ int i;
+
+ for (i = 0; i < mc_saved_count; i++)
+ mc_saved[i] = (struct microcode_intel *)
+ (mc_saved_in_initrd[i] + initrd_start);
+}
+
+#ifdef CONFIG_X86_32
+static void __cpuinit
+microcode_phys(struct microcode_intel **mc_saved_tmp,
+ struct mc_saved_data *mc_saved_data)
+{
+ int i;
+ struct microcode_intel ***mc_saved;
+
+ mc_saved = (struct microcode_intel ***)
+ __pa_symbol(_saved_data->mc_saved);
+ for (i = 0; i < mc_saved_data->mc_saved_count; i++) {
+ struct microcode_intel *p;
+
+ p = *(struct microcode_intel **)
+ __pa(mc_saved_data->mc_saved + i);
+ mc_saved_tmp[i] = (struct microcode_intel *)__pa(p);
+ }
+}
+#endif
+
+static enum ucode_state __cpuinit
+load_microcode(struct mc_saved_data *mc_saved_data,
+ unsigned long *mc_saved_in_initrd,
+ unsigned long initrd_start,
+ struct ucode_cpu_info *uci)
+{
+ struct microcode_intel *mc_saved_tmp[MAX_UCODE_COUNT];
+ unsigned int count = mc_saved_data->mc_saved_count;
+
+ if (!mc_saved_data->mc_saved) {
+ microcode_pointer(mc_saved_tmp, mc_saved_in_initrd,
+ initrd_start, count);
+
+ return generic_load_microcode_early(mc_saved_tmp, count, uci);
+ } else {
+#ifdef CONFIG_X86_32
+ microcode_phys(mc_saved_tmp, mc_saved_data);
+ return generic_load_microcode_early(mc_saved_tmp, count, uci);
+#else
+ return generic_load_microcode_early(mc_saved_data->mc_saved,
+ count, uci);
+#endif
+
[PATCH v4 10/11] x86/mm/init.c: Copy ucode from initrd image to kernel memory
From: Fenghua Yu
Before initrd image is freed, copy valid ucode patches from initrd image
to kernel memory. The saved ucode will be used to update AP in resume
or hotplug.
Signed-off-by: Fenghua Yu
---
arch/x86/mm/init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 5f59473..36bad16 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -16,6 +16,7 @@
#include
#include
#include/* for MAX_DMA_PFN */
+#include
#include "mm_internal.h"
@@ -555,6 +556,15 @@ void free_initmem(void)
#ifdef CONFIG_BLK_DEV_INITRD
void __init free_initrd_mem(unsigned long start, unsigned long end)
{
+#ifdef CONFIG_MICROCODE_EARLY
+ /*
+* Remember, initrd memory may contain microcode or other useful things.
+* Before we lose initrd mem, we need to find a place to hold them
+* now that normal virtual memory is enabled.
+*/
+ save_microcode_in_initrd();
+#endif
+
/*
* end could be not aligned, and We can not align that,
* decompresser could be confused by aligned initrd_end
--
1.8.0.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 v4 08/11] x86/head_32.S: Early update ucode in 32-bit
From: Fenghua Yu This updates ucode in 32-bit kernel. At this point, there is no paging and no virtual address yet. Signed-off-by: Fenghua Yu --- arch/x86/kernel/head_32.S | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 8e7f655..fdc11f6 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -144,6 +144,12 @@ ENTRY(startup_32) movl %eax, pa(olpc_ofw_pgd) #endif +#ifdef CONFIG_MICROCODE_EARLY + /* Early load ucode on BSP. */ + movl $pa(boot_params), %eax + call load_ucode_bsp +#endif + /* * Initialize page tables. This creates a PDE and a set of page * tables, which are located immediately beyond __brk_base. The variable @@ -299,6 +305,12 @@ ENTRY(startup_32_smp) movl %eax,%ss leal -__PAGE_OFFSET(%ecx),%esp +#ifdef CONFIG_MICROCODE_EARLY + /* Early load ucode on AP. */ + call load_ucode_ap +#endif + + default_entry: /* * New page tables may be in 4Mbyte page mode and may -- 1.8.0.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 v4 01/11] Documentation/x86: Early load microcode
From: Fenghua Yu Documenation for early loading microcode methodology. Signed-off-by: Fenghua Yu --- Documentation/x86/early-microcode.txt | 43 +++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/x86/early-microcode.txt diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt new file mode 100644 index 000..4aaf0df --- /dev/null +++ b/Documentation/x86/early-microcode.txt @@ -0,0 +1,43 @@ +Early load microcode + +By Fenghua Yu + +Kernel can update microcode in early phase of boot time. Loading microcode early +can fix CPU issues before they are observed during kernel boot time. + +Microcode is stored in an initrd file. The microcode is read from the initrd +file and loaded to CPUs during boot time. + +The format of the combined initrd image is microcode in cpio format followed by +the initrd image (maybe compressed). Kernel parses the combined initrd image +during boot time. The microcode file in cpio name space is: +kernel/x86/microcode/GenuineIntel.bin + +During BSP boot (before SMP starts), if the kernel finds the microcode file in +the initrd file, it parses the microcode and saves matching microcode in memory. +If matching microcode is found, it will be uploaded in BSP and later on in all +APs. + +The cached microcode patch is applied when CPUs resume from a sleep state. + +There are two legacy user space interfaces to load microcode, either through +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file +in sysfs. + +In addition to these two legacy methods, the early loading method described +here is the third method with which microcode can be uploaded to a system's +CPUs. + +The following example script shows how to generate a new combined initrd file in +/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and +original initrd image /boot/initrd-3.5.0.img. + +mkdir initrd +cd initrd +mkdir kernel +mkdir kernel/x86 +mkdir kernel/x86/microcode +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin +find .|cpio -oc >../ucode.cpio +cd .. +cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img -- 1.8.0.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 v4 00/11] x86/microcode: Early load microcode
From: Fenghua Yu The problem in current microcode loading method is that we load a microcode way, way too late; ideally we should load it before turning paging on. This may only be practical on 32 bits since we can't get to 64-bit mode without paging on, but we should still do it as early as at all possible. Similarly, we should load the microcode update as early as possible during AP bringup and when processors are brought back online after hotplug or S3/S4. In order to do that, the microcode patch needs to be permanently present in kernel memory. Each individual patch is fairly small, so that is OK, but the entire blob with support for each CPU is too big. Since only CPU's with same model can be in the same platform, we store microcode with the same model as BSP. Later on APs can upload microcode from the saved microcodep patches. Note, however, that Linux users have gotten used to being able to install a microcode patch in the field without having a reboot; we support that model too. In x86_64, this patchset needs early #PF handler set page table patchset. So this patchset is based on: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot v4: Change CPUID_IS macro. Call load_ucode_bsp after load_idt in x86_64. Flush tlb after applying microcode. v3: Change .hex to .bin in 01/10 and 05/10 patches. Fix some compilation warnings. In x86_32 mode, access global varialbes by __pa_symobl() and fix static string issue in x86_vendor(). Call load_ucode_ap() in real mode as well. Add debug info. v2: Detect vendor before loading microcode. Move some functions from microcode_intel_early.c to microcode_intel_lib.c. Change some early loading microcode dependencies in Kconfig. Reword doc. Fenghua Yu (11): Documentation/x86: Early load microcode x86/microcode_intel.h: Define functions and macros for early loading ucode x86/common.c: Make have_cpuid_p() a global function x86/microcode_core_early.c: Define interfaces for early loading ucode x86/microcode_intel_lib.c: Early update ucode on Intel's CPU x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled() x86/microcode_intel_early.c: Early update ucode on Intel's CPU x86/head_32.S: Early update ucode in 32-bit x86/head64.c: Early update ucode in 64-bit x86/mm/init.c: Copy ucode from initrd image to kernel memory x86/Kconfig: Configurations to enable/disable the feature Documentation/x86/early-microcode.txt | 43 ++ arch/x86/Kconfig| 18 + arch/x86/include/asm/microcode.h| 14 + arch/x86/include/asm/microcode_intel.h | 85 arch/x86/include/asm/processor.h| 8 + arch/x86/include/asm/tlbflush.h | 18 +- arch/x86/kernel/Makefile| 3 + arch/x86/kernel/cpu/common.c| 17 +- arch/x86/kernel/head64.c| 6 + arch/x86/kernel/head_32.S | 12 + arch/x86/kernel/microcode_core.c| 7 +- arch/x86/kernel/microcode_core_early.c | 76 +++ arch/x86/kernel/microcode_intel.c | 198 ++-- arch/x86/kernel/microcode_intel_early.c | 792 arch/x86/kernel/microcode_intel_lib.c | 174 +++ arch/x86/mm/init.c | 10 + 16 files changed, 1298 insertions(+), 183 deletions(-) create mode 100644 Documentation/x86/early-microcode.txt create mode 100644 arch/x86/include/asm/microcode_intel.h create mode 100644 arch/x86/kernel/microcode_core_early.c create mode 100644 arch/x86/kernel/microcode_intel_early.c create mode 100644 arch/x86/kernel/microcode_intel_lib.c -- 1.8.0.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 00/19] Numa aware LRU lists and shrinkers
On Thu, Dec 20, 2012 at 03:45:28PM +0400, Glauber Costa wrote:
> On 11/28/2012 03:14 AM, Dave Chinner wrote:
> > Hi Glauber,
> >
> > Here's a working version of my patchset for generic LRU lists and
> > NUMA-aware shrinkers.
.
> > There's still a bunch of cleanup work needed. e.g. the LRU list
> > walk/isolation code needs to use enums for the isolate callback
> > return code, there needs to be a generic list_lru_for_each() style
> > function for walking all the objects in the cache (which will allow
> > the list_lru structures to be used for things like the per-sb inode
> > list). Indeed, even the name "list_lru" is probably something that
> > should be changed - I think the list has become more of a general
> > per-node list than it's initial functionality as a scalable LRU list
> > implementation and I can see uses for it outside of LRUs...
> >
> > Comments, thoughts and flames all welcome.
> >
>
> I like the general idea, and after a small PoC on my side, I can say it
> can at least provide us with a good and sound route to solve the
> targetted memcg shrinking problem.
>
> I've already provided you some small feedback about the interface in the
> specific patches.
*nod*
> But on a broader sense: The only thing that still bothers me personally
> (meaning: it created particular pain points), is the very loose coupling
> between all the elements involved in the shrinking process:
>
> 1) the shrinker, always present
> 2) the lru, usually present
> 3) the cache, usually present, specially when there is an LRU.
>
> I of course understand that they are not always present, and when they
> are, they are not in a 1:1 relation.
>
> But still, it would be nice to be able to register them to one another,
> so that we can easily answer things like:
>
> "Given a set of caches, what is the set of shrinkers that will shrink them?"
>
> "What are the lrus that are driven by this shrinker?"
>
> This would allow me to do things like this:
>
> * When a per-memcg cache is created (not all of the caches are
> replicated), find the shrinkers that can shrink them.
>
> * For each shrinker, also replicate the LRUs that are driven by them.
>
> Does that make any sense to you ?
It certainly does, though I see that as a separate problem to the
one that this patch set solves. i.e. this is an issue related to the
scope and context of a shrinker/LRU couplet, rather than the
implementation of a shrinker/LRU couplet. This patchset addresses
the latter of the two, and I'm pretty sure that I mentioned that the
former was not a problem I am trying to solve yet
As it is, right now we embed the struct shrinker into the owner
context, and that's how we find the LRU/cache instances that the
shrinker operates on. In the case of per-memcg shrinker
instantiation that fixed relationship does not work.
Further, the struct shrinker has context specific information in it,
like the defered scan count that it carries from one invocation to
the next, so what we end up with is a tightly coupled owner/shrinker
relationship. That is, a shrinker is really made up of four things:
- a shrinker definition (set of methods and configuration
data)
- a non-volatile set of data
- the owner context
- the LRU/cache to be shrunk
I suspect that a shrinker instance would look something like this:
shrinker_instance {
non-volatile set of data
LRU/cache to be shrunk
pointer to the owner context
pointer to the shrinker definition
}
But I'm not really sure how to group them sanely, how to know what
shrinkers would need multiple instantiation and when you'd do that
instantiation, or even how an owner context would then do global
operations (e.g empty caches prior to unmount).
I simply don't know what the requirements for such infrastructure
is, so I can't really say much more than this. Hence I think the
first thing to do here is work out and document what such
instantiation, tracking and grouping needs to be able to do before
anything else...
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/
Re: [GIT PULL] notification tree changes for 3.8
On Thu, 2012-12-20 at 17:50 -0800, Linus Torvalds wrote:
> On Thu, Dec 20, 2012 at 2:38 PM, Eric Paris wrote:
> > I believe you would get a build failure after this pull due to the
> > addition of procfs information for *notify fds. The attached patch from
> > sfr should be applied during the merge to change the spin_lock in that
> > patch to the mutex in this patch.
>
> I'm not going to bother pulling this.
>
> It's coming in late in the merge window, it has been rebased days ago,
> and it changes fundamental infrastructure.
>
> This has been a huge merge window, and this is just too late and too
> surprising. The commits are marked as being written 18 months ago, but
> then the commit date is after the merge window started, and sent the
> day before it closes.
>
> WTF? If they've waited 18 months, there cannot be this kind of
> last-minute hurry now. Why did you wait until the last minute?
The changes have been in next for about 18 months. I've just been a
missing maintainer. I'm back with some time to fix that fact, but I
understand if you want to reject it on that account. I'm available now
if something goes wrong. Most of this work was originally done just as
cleanup, but recently people started complaining about the FAT race/NULL
ptr deref.
https://bugzilla.redhat.com/show_bug.cgi?id=768534
Which got me to finally get off my lazy ass. When looking to send the
pull request on the first day of the window I realized just how far
behind my tree was and that there was a merge conflict for which sfr had
been carrying a patch forever. With 3.7 less than a day old I figured
3.6 was a good place to go in order to solve the conflict. Since I
rebased, it obviously needed more testing and some time in -next. Which
was why I said to you, back on the 11th, that I was planning to send my
pull request today.
http://marc.info/?l=linux-next=135526314222685=2
It is a locking change, but if anything goes wrong, at least I've got
time without other work commitments over the next 2 weeks to fix them.
If you are wondering about testing, I've written the attached
notification stressor. On a dual core box it will cause a kernel panic
is about 1 second on your kernel. With the patch set it doesn't pop...
Your call, but it does fix a real bug that people are reporting today.
-Eric
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* huerristic on how hard to load a box */
static unsigned int num_cores;
/* number of threads which just read from inotify_fd and ignore the results */
static unsigned int num_data_dumpers;
/* each thread will add a watch to a given file as fast as it can */
static unsigned int num_adder_threads;
/* each thread will remove all watches between low and high as fast as they can */
static unsigned int num_remover_threads;
/* a multiplier for adders and removers so you have X adders per file */
static unsigned int watcher_multiplier;
/* this removes watches from low_wd to low_wd + 3 just for extra removal races */
static unsigned int num_low_remover_threads;
/* create and destroy the files watches are being added to and removed from */
static unsigned int num_file_creaters;
/* how many inotify_fd's we have total (so another multiplier for adders and removers) */
static unsigned int num_inotify_instances;
static char *working_dir = "/tmp/inotify_syscall_thrash";
/* if mounting a real filesystem, where is the source? (doesn't matter for tmpfs) */
static char *mnt_src;
/* what is the fstype to mount and unmonut? */
static char *fstype = "tmpfs";
static pthread_attr_t attr;
static pthread_mutex_t wait_mutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t wait_var = PTHREAD_COND_INITIALIZER;
static int wait;
#define WAIT_CHILD do {\
pthread_mutex_lock(_mutex); \
if (wait == 0) \
pthread_cond_wait(_var, _mutex); \
wait = 0; \
pthread_mutex_unlock(_mutex); \
} while (0);
#define WAKE_PARENT do {\
pthread_mutex_lock(_mutex); \
wait = 1; \
pthread_cond_signal(_var); \
pthread_mutex_unlock(_mutex); \
} while (0);
struct adder_struct {
int inotify_fd;
int file_num;
};
struct operator_struct {
int inotify_fd;
};
struct thread_data {
int inotify_fd;
pthread_t *adders;
pthread_t *removers;
pthread_t *lownum_removers;
pthread_t *data_dumpers;
};
pthread_t *file_creaters;
pthread_t low_wd_reseter;
pthread_t mounter;
static int stopped = 0;
static int high_wd = 0;
static int low_wd = INT_MAX;
static int handle_error(const char *arg)
{
perror(arg);
exit(EXIT_FAILURE);
}
static void sigfunc(int sig_num)
{
if (sig_num == SIGINT)
stopped = 1;
else
printf("Got an unknown signal!\n");
}
/* constantly create and delete all of the files that are bieng watched */
static void *__create_files(__attribute__ ((unused)) void *ptr)
{
char filename[50];
unsigned int i;
fprintf(stdout, "Starting creater thread\n");
WAKE_PARENT;
while
[PATCH] rtk_btusb: Add Bluetooth firmware
Signed-off-by: Larry Finger
Signed-off-by: Champion Chen
---
WHENCE |8
rtl_bt/rtl8723a.bin | Bin 0 -> 23772 bytes
2 files changed, 8 insertions(+)
create mode 100644 rtl_bt/rtl8723a.bin
diff --git a/WHENCE b/WHENCE
index 3b2f282..f485111 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1811,6 +1811,14 @@ Licence: Redistributable. See
LICENCE.rtlwifi_firmware.txt for details.
--
+Driver: rtk_btusb - Realtek Bluetooth driver
+
+Info: Supplied by champion_c...@realsil.com.cn along with driver source code
+File: rtl_bt/rtl8723a.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--
Driver: r8169 - RealTek 8169/8168/8101 ethernet driver.
diff --git a/rtl_bt/rtl8723a.bin b/rtl_bt/rtl8723a.bin
new file mode 100644
index
..1a43ce2e9585f83434d15503b36049584657b81f
GIT binary patch
literal 23772
zcmc({dwdk-y+1y)w`?|>WD-KMgxj(Ng(Y0vfX7?g$pr{u1Bg^2g3jjRBzs99pj8WX
zineNvJ&=oF2(sovAz3u+25e7D8$)an(iRp(MXWJk8+H@eAVQDFc7N~BY!+hA_x#T5
z``7oiuV-d<=9y=n%jfxA-k;C{d$+R-aa#`k8my4aV_GmvG``?;Y0@98869qSS62
zDeSf2xV(1)jw^cgIIiqfk_2e%2Q`K7;EY`Xa|?y+7@uf6wCHmeJ!6alO??$1UC;`HVeVyo{lA
zF7DwU>wIO1Iq^fZgr2evrss!fFaFa#B)T4(q<^_LHs8NKqxanB|CcoS9RYdK;|@pA
z*z+vD_${RbiZD+2k
zN*LypDoOGqU0{+VhG7i7uXEDxkrd5I(r<9@=sTR0hx3FEPO_?#r1eMeALoO;oKzH>
zBz^u@PTH92`kMjp-IO%DeD?Z|+e!O@30w-O<`Q=YJX$$VZinE0C
zp}!y>-v6SXlQ`7t(C3_F!1v!9;G~zR9GoxUy~=_7g{=OX0aiu(E8Nzy4?Z~TIj
zGSF@Y=`8Y8oJE^)U5K1m`bND|TuNG~D%45b9pBaim-BkPdX_r~JiW4(#j7`p)8qCsv69OqfP
zdxY=JvUgvz_6>$oaJT!~^1kdnm4TUN#ap_<8OF)JoJG08X}0d>a8>x`ROe!GD4;B;
z3FHo@*%o~&0
z`H#Ngq)-_2z$8iD!7w|2^SIqs<=%_m@0k8#82A6HL|YtlT60Pz?F?Qy9#;&6x
zb3N~)>me?=lASXIx>jdA(TPj#}BR!BR`bfYsuVQ-Uua|N2AAn%Qcd5a;a_8AJc%
z=Nn_pjKMx7NmOx+;fHIsi%H_?S=ya3J2aSy>XLjRNou+)Nt%6_aj;I5S{1I`fO7It
zYQE*b0JwE?O+aH}Mphjh3M>iM1nx1j%ld-aM~7@vk1~%XusJ>4CgfPk^mf+W01Q
zb%ww$^8}TTUbUs7?68yS8Z9-aQB|FS=QVi#r7iK+^JrV>%hZw@l%}wOV(gSx_vkRL
zS$omqB+0rpN!s;zl0@~7_FLHDyrOzacUFDw2R6Rd8BkXz*}mJ!?^+RvH%W#KkRNQd
z)`p%nq)%a7bkyujTocqoN)o
ztsg2JLLXH`Mk2|yM=bYberpt_-x>uy>K?yGzv7Glruts~c{QE6q>p8{#Wt=dTj8i*H45f{|j#Y
zFBA2L<(VAp-lNWBL1P=TlI$9e-5g`1f19(WVZK{P~=fU5Zv;
zX7h0z)E1qyG39!cns528k4kk7;JK>->#dk=wq9vTx#4u=(Nb;&$;6xDn|BIxb$OK+H~aoLAo^
zG`z!}i`qy?`A`0MV4{|Cfj?TZy`b!~YD2!~Y2LO-i3L
zU>xKxFie>FCj4cIp*Zby>M2mJ-56SV?3`ETALV>=ivO&4S34hi>7+6AOtUexwwVWq
z%nT&>|19?q=l>JtOQL*?_x};sN%=gqvG@8{6eNuGK6O-MTJ>eUYc}Nt;hHrcr_mt+}dJFOIsK|%*A0#QNF82g711j`V
z>*R#`M97E(ILC2^eKlj=@_DWJ7h9fK$5uRH$qeL}I=c9#hjB%<;p__M{KC^B)u(V!
zV>a3g2hmEGXV8$u)vp&(ujajndDJRXt`)y0eRdOgBGpT2-X+&)D{55UK{djgPG_Lz
zR-N>tb<%P>@D9~VY5uufpTq{%(Qa`D3QR8@;$L4JOmsK{%IaJpY(FZp1uE1@A@@I^*k~#5>mi{tkWBT;-)FRR6+3#$opgJmM@0p4X;C}n
zXzgOmD)~L4Y3tyRxb?nxjPn{_Wgyf1;GskZ+9uaT2;fiF*V1}X#b=IQ7wzA{Kv9`gcgeBC(I
zSZzo@F7+mVVH8()$Q
z1A^=Z(yQ_?7x__sLGzM$hI2C67(5dWKZiN`yD-BT@dn4FA%8gh8SY)hJvWoLgOe;f
zpPBwN-eZ|ImSMV)Z$87iT8Co18tAcnV`abtz4onJdTdli{kF@Q7FG0$tB7^2Xq-`*4=n{W|MBXQ>HH
zF=_3E!wSnPT!W|(J1qRo;;iM+QlAed2ppalc!!1y2N#Pq;KPf(g@c&0!$ZTm
zv*n`Q!dCVLQcb*lmRL9}y`D`oWpJB3k|zR6;WbNNAO@6HI4sla@O^muJ}>0Dxj>8o
zEwK*k;5}YSLeDIpvVz}DRFFwC%(ejc=Obl#UlKJR#GL)wrE;=greb6#RH;s@{WP-L
zQ@Yw@(`?^LnUdnn2H)5cCgW?A3|{8^bT2fA#^0iyX(s+F1_pWO<-67y;FAk_|-@DFinkTH`o`V*%EU@
zV(o(ht~V)dvr%*5yxEKS-bnLZiT;`iN6K`C~Lc
znOSbP;GT{)n>d5lQA!e-Qm?s9(k^W
zyP1EKsERed`F6(1f1(B^fI2s;b~0C$kh!Es(tBg%dqw6I#b*84_zx04RG(XEd%+v7
zU_E1C^1%N1^iv^RgIIoB*|
zUNgy7)37u^1(IPaRQjsA_zt#!KgqY^*xMISt<~5ZplEk5bAouf{aajZ
zoJ|C6cHhjgd}EI1^mWQjI@?;zbgH9mOda(NswbsToGrdK43vsEBv*}p4LNN!0R{4|
z0af--{&6E?|2Y?SEy8nk^;}zgU3`6BOQOSrmX);f77whNCeQ$*XYku$4W5JHh{iktNNZfXV#X
zjnc);$jaR{fl080R=0S-fzv<@y?1LqSUg`(y`k;{=$-od?h}o%8B%8I81H(CTxH`{*MxMvFa4~Yxxx?b3PeTi8;?0
z8nc+PH=K0t6cf4%zDkA6BRXXBt%K07iiEzeZ84Zr>Yc)Q)poK)VGGFofW!D1kwOe}
zBvLl-A>jF{XEJ4TMo~%O#BA@JE+8J@pSnu2H0X+uNTz3}@
zdKUim-k5y!j4;=kcxy~LkL&-xbOO(jgj?^ZcLMdakMcRtWE4vy+uVxu{~G6`Ibran
zfg?+Eg!5^*%IH$>*<9)8c(hJn;zRV#^OxMJd!Ne*3LlwY2a$~F9yimdT~GDa+Obro^N47agZ|`2Oe+IJF=T&
z=S6v)=XMOYM>`SvG_lI$K1)-VQKGTD|BbOZ{$FS(xT2Q8o{Mb^Sd+lt`
z3H>H^ud7OdS=Io|zVvZ$;xK${w+Bu}ctVy5CluhB-kh*#zxIkt;QF;V&;oJ!hQ2T<##L0?oU+Q3y?a@
z_15#-;9t4H8S3%Bs6V@iu99xFYE+ET|%>wL7FXB{lGEna~?n*`DcS?cbq+3_nbhz?E73-7n{!A4@;
zqhh9vcP}UmSKlkF7oTlk)P;NBnpgRjmw~E+$6tH;#Ipzg`?F++JM{F4+d9
z(~)%0k&^28mb-!Y<;Z%JsXE1$)G%4RCm)zAT0M8JrZPJ3`9ckN03VVL8Vxy9QeBZT
znrut&3RggntTxz~-IAL|Dsw2=#JjH*WCj##<89+)O^C;QHD1?Nt8EE~G4h7sL;QP;
z!BAwVPu)3wM+$5dy=8@@P-zH4$p7@h|i7ElH+=PT(tcX+MXaFn<>7*P0fAYWZU`E>p??*Ht|SSV}e%t%f%)k%Y-Fx>%*WxiKm{^U=Xpsx
zWZKnr%nfE?sYO#)c)8pXgQL@;#c_ir7RSvN9ga_1;&9wzDZFg7@Rq`1<8>u$*Qs7x
zBj4B~s;2)iz|Q_+F!@S?7vH+VH!GkCA>S3fPwy3W^Nke)yk#|bX%5~7PH)JZU3i7t
znYbeXV-s6)9DPsv<-hvVN-f#EuIp@`V~_#OTSo*(o}v9DAY1o
Re: [GIT PULL v2] ARM: arm-soc fixes for 3.8
On Thu, 2012-12-20 at 11:00 -0800, Linus Torvalds wrote: > Hmm. The patch there looks better than any alternative I can think of. > It uses the same spinlock name for the whole array, but I think it's > only used for lockdep printouts, so that should be fine. > > Send me the patch with signed-off and tested-by, and perhaps have a > few more people test it. The powerpc and sparc people both use it in > their 32-bit versions and have responsible maintainers, so it might be > worth it double-checking with BenH and DaveM about it, just in case. > Added to the Cc. The patch looks fine. I won't personally be able to test it until after I'm back from vacation though. I'll see if I can get somebody else to but don't wait for me. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the signal tree with Linus' tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/h8300/include/asm/signal.h between commit 1ec94e75def5 ("UAPI:
(Scripted) Disintegrate arch/h8300/include/asm") from Linus' tree and
commit 031b6566983a ("unify SS_ONSTACK/SS_DISABLE definitions") from the
signal tree.
I just used the former version, but removed the SS_* constants from the
uap version of the include files as well and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQAstBmeQpN.pgp
Description: PGP signature
linux-next: manual merge of the signal tree with Linus' tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/m32r/include/asm/signal.h between commit f7f4dc10e1eb ("UAPI:
(Scripted) Disintegrate arch/m32r/include/asm") from Linus' tree and
commit 031b6566983a ("unify SS_ONSTACK/SS_DISABLE definitions") from the
signal tree.
I just used the former version, but removed the SS_* constants from the
uap version of the include files as well and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpNETbbnLPTm.pgp
Description: PGP signature
[PATCH v2] atkbd: Fix multi-char scancode handling on reconnect.
On resume from suspend there is a possibility for multi-byte scancodes
to be handled incorrectly. atkbd_reconnect disables the processing of
scancodes in software by calling atkbd_disable, but the keyboard may
still be active because no disconnect command was sent. Later, software
handling is re-enabled. If a multi-byte scancode sent from the keyboard
straddles the re-enable, only the latter byte(s) will be handled.
In practice, this leads to cases where multi-byte break codes (ex. "e0
4d" - break code for right-arrow) are misread as make codes ("4d" - make
code for numeric 6), leading to one or more unwanted, untyped characters
being interpreted.
The solution implemented here involves sending command f5 (reset
disable) to the keyboard prior to disabling software handling of codes.
Later, the command to re-enable the keyboard is sent only after we are
prepared to handle scancodes.
Signed-off-by: Shawn Nematbakhsh
---
Changes since v1:
- Removed unused return values from atkbd_deactivate.
drivers/input/keyboard/atkbd.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index add5ffd..44dcf83 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -844,6 +844,20 @@ static int atkbd_activate(struct atkbd *atkbd)
}
/*
+ * atkbd_deactivate() resets and disables the keyboard from sending
+ * keystrokes.
+ */
+static void atkbd_deactivate(struct atkbd *atkbd)
+{
+ struct ps2dev *ps2dev = >ps2dev;
+
+ if (ps2_command(ps2dev, NULL, ATKBD_CMD_RESET_DIS))
+ dev_err(>serio->dev,
+ "Failed to deactivate keyboard on %s\n",
+ ps2dev->serio->phys);
+}
+
+/*
* atkbd_cleanup() restores the keyboard state so that BIOS is happy after a
* reboot.
*/
@@ -1199,6 +1213,9 @@ static int atkbd_reconnect(struct serio *serio)
mutex_lock(>mutex);
+ if (atkbd->write)
+ atkbd_deactivate(atkbd);
+
atkbd_disable(atkbd);
if (atkbd->write) {
@@ -1208,8 +1225,6 @@ static int atkbd_reconnect(struct serio *serio)
if (atkbd->set != atkbd_select_set(atkbd, atkbd->set,
atkbd->extra))
goto out;
- atkbd_activate(atkbd);
-
/*
* Restore LED state and repeat rate. While input core
* will do this for us at resume time reconnect may happen
@@ -1224,6 +1239,9 @@ static int atkbd_reconnect(struct serio *serio)
}
atkbd_enable(atkbd);
+ if (atkbd->write)
+ atkbd_activate(atkbd);
+
retval = 0;
out:
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ksm: make rmap walks more scalable
On Fri, 21 Dec 2012, Petr Holasek wrote: > On Thu, 20 Dec 2012, Sasha Levin wrote: > > On 12/20/2012 05:37 PM, Hugh Dickins wrote: > > > > > > To stop these oopses in get_mergeable_page (inlined in > > > unstable_tree_search_insert) you need the patch I showed on > > > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > > > all of the problems, but hopefully all that you'll encounter before > > > I've devised a fix for the separate stale stable_nodes issue. > > > > My bad! I thought that this is the finalized version of the patch from > > Tuesday and was surprised when the oops was still there :) > > > > fwiw I'll use this to report that I'm not seeing any unexpected behaviour > > with this patch applied. Thanks, Sasha. > > Hugh, big thanks for your Tuesday fix, I am not able to reproduce reported > oops any more. I will continue with testing overnight and submit v6 version > tomorrow if there won't be any problem. Great, thank you Petr. > > Should I also add [PATCH] ksm: make rmap walks more scalable into v6 or > can I rely on it? No, this rmap walks patch is entirely independent of your changes, and already picked up by Linus into his tree for rc1. By all means test with it in, or out, but don't fold it into your v6: Andrew's mmotm posted just now has it already in too. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.7-nohz1
On Thu, 2012-12-20 at 19:32 +0100, Frederic Weisbecker wrote: > Hi, > Nice work Frederic! > So this is a new version of the nohz cpusets based on 3.7, except it's not > using > cpusets anymore and I actually based it on the middle of the 3.8 merge window > in order to get latest upstream full dynticks preparatory work: cputime > cleanups, > RCU user mode, context tracking subsystem, nohz code consolidation, ... > > So the big changes since the last nohz cpuset release are: > > * printk now uses irq work so it doesn't rely on the tick anymore (provided > your arch implements irq work with IPIs or alike). This chunk has been > proposed > for the 3.8 merge window: https://lkml.org/lkml/2012/12/17/177 > May be Linus will pull, may be not. We'll see. In any case I've included it > in this tree > but I'm not reposting this part of the patchset to avoid spamming you. > > * cputime doesn't rely on IPIs anymore. Now the reader does a special > computation to > remotely get the tickless cputime. > > * No more cpusets interface. Paul McKenney suggested me to start with a boot > time > kernel parameter to define the full dynticks cpumask. And he was totally > right, it > makes the code much more simple. That's a good way to start and to make the > mainlining > easier. We can still add a runtime configuration later if necessary. > > * Now there is always a CPU handling the timekeeping. This can be further > optimized > and more power-friendly, I really did something simple-stupid. I guess we'll > try to get > that into a better shape with Hakan. But at least the timekeeping now works. > > * It uses the new RCU callbacks offlining feature. This way a full dynticks > CPU doesn't > need to keep the tick to handle local callbacks. This is still very > experimental though. > > * No more specific IPI vector for full dynticks. We just use the scheduler > ipi. > > The branch is: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > 3.7-nohz1 > > There is still quite some work to do. > > == How to use? == > > Select: > CONFIG_NO_HZ > CONFIG_RCU_USER_QS > CONFIG_VIRT_CPU_ACCOUNTING_GEN > CONFIG_RCU_NOCB_CPU > CONFIG_NO_HZ_FULL > > You always need at least one timekeeping CPU. > > Let's imagine you have 4 CPUs. We keep the CPU 0 to offline RCU callbacks > there and to > handle the timekeeping. We set the rest as full dynticks. So you need the > following kernel > parameters: > > rcu_nocbs=1-3 full_nohz=1-3 > > (Note rcu_nocbs value must always be the same as full_nohz). Why? You can't have: rcu_nocbs=1-4 full_nohz=1-3 or: rcu_nocbs=1-3 full_nohz=1-4 ? That needs to be fixed. Either with a warning, and/or to force the two to be the same. That is, if they specify: rcu_nocbs=1-3 full_nohz=1-4 Then set rcu_nocbs=1-4 with a warning about it. Or simply set full_nohz=1-3. -- Steve > > Now if you want proper isolation you need to: > > * Migrate your processes adequately > * Migrate your irqs to CPU 0 > * Migrate the RCU nocb threads to CPU 0. Example with the above configuration: > > for p in $(ps -o pid= -C rcuo1,rcuo2,rcuo3) > do > taskset -cp 0 $p > done > > Then run what you want on the full dynticks CPUs. For best results, run 1 task > per CPU, mostly in userspace and mostly CPU bound (otherwise more IO = more > kernel > mode execution = more chances to get IPIs, tick restarted, workqueues, > kthreads, etc...) > > This page contains a good reminder for those interested in CPU isolation: > https://github.com/gby/linux/wiki > > But keep in mind that my tree is not yet ready for serious production. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the signal tree with Linus' tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/h8300/include/asm/ptrace.h between commit 1ec94e75def5 ("UAPI:
(Scripted) Disintegrate arch/h8300/include/asm") from Linus' tree and
commit 1ca97bb541a1 ("new helper: current_user_stack_pointer()") from the
signal tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/h8300/include/asm/ptrace.h
index 79c9a91,6183371..000
--- a/arch/h8300/include/asm/ptrace.h
+++ b/arch/h8300/include/asm/ptrace.h
@@@ -28,5 -63,7 +28,6 @@@
#define current_pt_regs() ((struct pt_regs *) \
(THREAD_SIZE + (unsigned long)current_thread_info()) - 1)
#define signal_pt_regs() ((struct pt_regs *)current->thread.esp0)
+ #define current_user_stack_pointer() rdusp()
-#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
#endif /* _H8300_PTRACE_H */
pgplthqKywVcN.pgp
Description: PGP signature
