Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
* Frederic Weisbecker wrote:
> From: Vatika Harlalka
>
> The problem addressed in this patch is about affining unpinned timers.
> Adaptive or Full Dynticks CPUs are currently disturbed by unnecessary
> jitter due to firing of such timers on them.
>
> This patch will affine timers to online CPUs which are not full dynticks
> in NOHZ_FULL configured systems. It should not introduce overhead in
> nohz full off case due to static keys.
>
> Reviewed-by: Preeti U Murthy
> Signed-off by: Vatika Harlalka
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Christoph Lameter
> Cc: Thomas Gleixner
> Cc: Paul E. McKenney
> Cc: Chris Metcalf
> Signed-off-by: Frederic Weisbecker
> ---
> include/linux/tick.h | 9 -
> kernel/sched/core.c | 7 +--
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 3741ba1..51e6493 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -143,13 +143,20 @@ static inline void tick_nohz_full_add_cpus_to(struct
> cpumask *mask)
> if (tick_nohz_full_enabled())
> cpumask_or(mask, mask, tick_nohz_full_mask);
> }
> -
> +static inline int housekeeping_any_cpu(void)
> +{
> + return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> +}
> extern void __tick_nohz_full_check(void);
> extern void tick_nohz_full_kick(void);
> extern void tick_nohz_full_kick_cpu(int cpu);
> extern void tick_nohz_full_kick_all(void);
> extern void __tick_nohz_task_switch(struct task_struct *tsk);
> #else
> +static inline int housekeeping_any_cpu(void)
> +{
> + return smp_processor_id();
> +}
> static inline bool tick_nohz_full_enabled(void) { return false; }
> static inline bool tick_nohz_full_cpu(int cpu) { return false; }
> static inline void tick_nohz_full_add_cpus_to(struct cpumask *mask) { }
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9917c96..4fd42e4 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -623,18 +623,21 @@ int get_nohz_timer_target(void)
> int i, cpu = smp_processor_id();
> struct sched_domain *sd;
>
> - if (!idle_cpu(cpu))
> + if (!idle_cpu(cpu) && is_housekeeping_cpu(cpu))
> return cpu;
>
> rcu_read_lock();
> for_each_domain(cpu, sd) {
> for_each_cpu(i, sched_domain_span(sd)) {
> - if (!idle_cpu(i)) {
> + if (!idle_cpu(i) && is_housekeeping_cpu(cpu)) {
> cpu = i;
> goto unlock;
> }
> }
> }
> +
> + if (!is_housekeeping_cpu(cpu))
> + cpu = housekeeping_any_cpu();
> unlock:
> rcu_read_unlock();
> return cpu;
So I almost applied this yesterday, but had the following question: what
ensures
that housekeeping_mask isn't empty? If it's empty then housekeeping_any_cpu()
returns cpumask_any_and() of an empty cpumask - which returns an out of range
index AFAICS - which will crash and burn in:
kernel/time/hrtimer.c: return _cpu(hrtimer_bases, get_nohz_timer_target());
kernel/time/timer.c:return per_cpu_ptr(_bases,
get_nohz_timer_target());
housekeeping_mask itself is derived from tick_nohz_full_mask (it's the inverse
of
it in essence), and tick_nohz_full_mask is set via two methods, either via a
boot
parameter:
if (cpulist_parse(str, tick_nohz_full_mask) < 0) {
in tick_nohz_full_setup(). What ensures here that tick_nohz_full_mask is not
completely full - making housekeeping_mask empty?
The other method is via CONFIG_NO_HZ_FULL_ALL:
cpumask_setall(tick_nohz_full_mask);
here it's fully set - triggering the bug I'm worried about. So what am I
missing,
what prevents CONFIG_NO_HZ_FULL_ALL from crashing?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm/vmalloc: Cache the /proc/meminfo vmalloc statistics
Linus wrote: > I don't think any of this can be called "correct", in that the > unlocked accesses to the cached state are clearly racy, but I think > it's very much "acceptable". I'd think you could easily fix that with a seqlock-like system. What makes it so simple is that you can always fall back to calc_vmalloc_info if there's any problem, rather than looping or blocking. The basic idea is that you have a seqlock counter, but if either of the two lsbits are set, the cached information is stale. Basically, you need a seqlock and a spinlock. The seqlock does most of the work, and the spinlock ensures that there's only one updater of the cache. vmap_unlock() does set_bit(0, >sequence). This marks the information as stale. get_vmalloc_info reads the seqlock. There are two case: - If the two lsbits are 10, the cached information is valid. Copy it out, re-check the seqlock, and loop if the sequence number changes. - In any other case, the cached information is not valid. - Try to obtain the spinlock. Do not block if it's unavailable. - If unavailable, do not block. - If the lock is acquired: - Set the sequence to (sequence | 3) + 1 (we're the only writer) - This bumps the sequence number and leaves the lsbits at 00 (invalid) - Memory barrier TBD. Do the RCU ops in calc_vmalloc_info do it for us? - Call calc_vmalloc_info - If we obtained the spinlock earlier: - Copy our vmi to cached_info - smp_wmb() - set_bit(1, >sequence). This marks the information as valid, as long as bit 0 is still clear. - Release the spinlock. Basically, bit 0 says "vmalloc info has changed", and bit 1 says "vmalloc cache has been updated". This clears bit 0 before starting the update so that an update during calc_vmalloc_info will force a new update. So the three case are basically: 00 - calc_vmalloc_info() in progress 01 - vmap_unlock() during calc_vmalloc_info() 10 - cached_info is valid 11 - vmap_unlock has invalidated cached_info, awaiting refresh Logically, the sequence number should be initialized to ...01, but the code above handles 00 okay. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] arm: dts: exynos: add vbus regulator to USB2 phy nodes
W dniu 21.08.2015 o 21:38, Marek Szyprowski pisze:
> Exynos USB2 PHY driver now supports VBUS regulator, so add it to all
> boards which have it available. This also fixes commit
> 7eec1266751bd3a25e35ce88686634c768fedc24 ("ARM: dts: Add Maxim 77693
> PMIC to exynos4412-trats2"), which added new regulators to Trats2 board,
> but without linking them to the consumers.
>
> Signed-off-by: Marek Szyprowski
Hi,
Thanks for taking care of it! Nice analysis.
1. If there would be a resend please change the "arm" to "ARM" in
subject. If not, maybe Kukjin can fix it when applying.
2. How about backporting 1st and 2nd patch to stable kernels? At least
for Trats2? Mentioned commit 7eec126675 introduces a bug (a feature
stops working) which would be nice to fix for stable releases as well.
We could also backport simpler patch, adding only "regulator-always-on".
3. What about safeout regulator #2? On Trats2 it goes to USB_VBUS of
modem. Shouldn't it be enabled?
I'll test the patchset later at work on my boards.
As for the code:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> ---
> arch/arm/boot/dts/exynos3250-monk.dts | 1 +
> arch/arm/boot/dts/exynos3250-rinato.dts | 1 +
> arch/arm/boot/dts/exynos4210-trats.dts | 2 +-
> arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +-
> arch/arm/boot/dts/exynos4412-trats2.dts | 1 +
> 5 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 540a0adf2be6..35b39d2255d3 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -161,6 +161,7 @@
> };
>
> _usbphy {
> + vbus-supply = <_reg>;
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 41a5fafb9aa9..23623cd3ebd9 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -153,6 +153,7 @@
>
> _usbphy {
> status = "okay";
> + vbus-supply = <_reg>;
> };
>
> {
> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
> b/arch/arm/boot/dts/exynos4210-trats.dts
> index ba34886f8b65..01d38f2145b9 100644
> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> @@ -251,6 +251,7 @@
>
> _usbphy {
> status = "okay";
> + vbus-supply = <_sreg>;
> };
>
> {
> @@ -448,7 +449,6 @@
>
> safe1_sreg: ESAFEOUT1 {
>regulator-name = "SAFEOUT1";
> - regulator-always-on;
> };
>
> safe2_sreg: ESAFEOUT2 {
> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
> b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> index eb379526e234..2c04297825fe 100644
> --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
> +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> @@ -248,6 +248,7 @@
>
> _usbphy {
> status = "okay";
> + vbus-supply = <_reg>;
> };
>
> {
> @@ -486,7 +487,6 @@
>
> safeout1_reg: ESAFEOUT1 {
> regulator-name = "SAFEOUT1";
> - regulator-always-on;
> };
>
> safeout2_reg: ESAFEOUT2 {
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 2a1ebb76ebe0..50a5e8a85283 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -391,6 +391,7 @@
> };
>
> _usbphy {
> + vbus-supply = <_reg>;
> status = "okay";
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] regulators: max77693: register driver earlier to avoid deferred probe
W dniu 21.08.2015 o 21:38, Marek Szyprowski pisze: > MAX77693 based regulators are used by USB gadget subsystem, which > doesn't support deferred probe, so the driver should be registered > before USB gadget drivers get probed. > > Signed-off-by: Marek Szyprowski > --- > drivers/regulator/max77693.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] nd_blk: add support for "read flush" DSM flag
On Thu, Aug 20, 2015 at 2:15 PM, Ross Zwisler wrote: > On Thu, 2015-08-20 at 13:27 -0700, Dan Williams wrote: > [...] >> With regards to the fencing, since we already take care to flush >> writes we don't need to fence at all for the flush, right? All we >> care about is that reads see valid data. > > We were careful to flush writes, but we could still have (now stale) data in > the cache either due to a previous read or because of prefetching. So we > need to flush, and we need to fence to make sure that our flushing stays > correctly ordered with respect to our reads. Hmm, so clflushopt does not guarantee that a read in program order after a clflushopt sees the invalidate? It seems like we're not getting any advantage of using clfushopt vs clflush. Let's go with this for now, but anything further should be guided by performance numbers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support
On 2015-08-21 06:26, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 4 +++
> arch/arm/boot/dts/vf500-colibri.dtsi| 47
> +
> 2 files changed, 51 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..14c0b00 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,7 @@
> model = "Toradex Colibri VF50 on Colibri Evaluation Board";
> compatible = "toradex,vf500-colibri_vf50-on-eval",
> "toradex,vf500-colibri_vf50", "fsl,vf500";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
> memory {
> reg = <0x8000 0x800>;
> };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
Since this is a touch screen related property, we even would want to
have that in the board specific device-tree (vf500-colibri-eval-v3.dts).
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
Hi Sanchayan,
On 2015-08-21 06:26, Sanchayan Maity wrote:
> +static int vf50_ts_probe(struct platform_device *pdev)
> +{
> + struct input_dev *input;
> + struct iio_channel *channels;
> + struct device *dev = >dev;
> + struct vf50_touch_device *touchdev;
> + int error;
> +
> + channels = iio_channel_get_all(dev);
> + if (IS_ERR(channels))
> + return PTR_ERR(channels);
Hm, we expect here that four channels are returned, however a faulty
device tree could contain less. Access to the fourth channel above would
lead to a bug.
Can you check the amount of channels returned? The returned list is
explicitly terminated with a null entry, you can rely on that. Something
similar to hwmon should do the job.
http://lxr.free-electrons.com/source/drivers/hwmon/iio_hwmon.c#L86
Otherwise, Acked-by: Stefan Agner
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] 9p regression fix
Fix for breakage introduced when switching p9_client_{read,write}() to
struct iov_iter * (went into 4.1). Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Vincent Bernat (1):
9p: ensure err is initialized to 0 in p9_client_read/write
Diffstat:
net/9p/client.c | 2 ++
1 file changed, 2 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen
On 2015-08-21 06:26, Sanchayan Maity wrote:
> This adds device tree binding documentation for the Colibri VF50
> touchscreen driver.
>
> Signed-off-by: Sanchayan Maity
> ---
> .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> new file mode 100644
> index 000..e615aa9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> @@ -0,0 +1,36 @@
> +* Toradex Colibri VF50 Touchscreen driver
> +
> +Required Properties:
> +- compatible must be toradex,vf50-touchscreen
> +- io-channels: adc channels being used by the Colibri VF50 module
> +- xp-gpios: FET gate driver for input of X+
> +- xm-gpios: FET gate driver for input of X-
> +- yp-gpios: FET gate driver for input of Y+
> +- ym-gpios: FET gate driver for input of Y-
> +- interrupt-parent: phandle for the interrupt controller
> +- interrupts: pen irq interrupt for touch detection
I like the use of the interrupt interface for the touch detection pin.
Maybe you can mention here that this is (typically) a GPIO...
> +- pinctrl-names: "idle", "default", "gpios"
> +- pinctrl-0: pinctrl node for idle state gpio pinmux
> +- pinctrl-1: pinctrl node for touch detection state pinmux
"touch detection" for default is rather confusing or even wrong. The
Idle state is used for pen/touch detection, default is used for X/Y and
Pressure measurement (maybe better described as touch measurement).
> +- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
> +- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values
> +
> +Example:
> +
> + touchctrl: vf50_touchctrl {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
Otherwise I agree with 1 and 2:
Acked-by: Stefan Agner
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Ping: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
On Sat, 22 Aug 2015, Frederic Weisbecker wrote: > Ping! Exellent!!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/11] soc: ti: knav_qmss_queue: fix error return code
On 8/22/15 5:11 PM, Julia Lawall wrote:
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
Acked-by: Santosh Shilimkar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mlxsw: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/mellanox/mlxsw/pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c
b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index a34f474..045f98f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -1726,6 +1726,7 @@ static int mlxsw_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
mlxsw_pci_dbg_root);
if (!mlxsw_pci->dbg_dir) {
dev_err(>dev, "Failed to create debugfs dir\n");
+ err = -ENOMEM;
goto err_dbg_create_dir;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/11] fix error return code
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c@i;
|
ret = -c@i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}
@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@
// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when !=
when any
(
if (<+... ret = e5 ...+>) S1
|
if (<+... ...+>) S1
|
if@p2(<+...x = fn(...)...+>)
{
... when != ret = e6
when forall
return@p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+=e4\|ret-=e4\)
when !=
(
if (<+... ret = e3 ...+>) S
|
if (<+... ...+>) S
|
if@p2(<+...\(x != 0\|x < 0\|x == NULL\|IS_ERR(x)\)...+>)
{
... when != ret = e2
when forall
return@p3 ret;
}
)
)
... when any
}
@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@
f(...) { <...pr@p(...,c,...)...> }
@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@
f(...) { ... when any
g@p(...,ret,...)
... when any
}
@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@
// ignore the above if there is some path where the variable is set to
// something else
(
if@p1 (\(ret < 0\|ret != 0\)) S1
|
ret@p1 = 0
)
... when any
\(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\|\)
... when any
if@p2(...) S2
@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@
ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when !=
when any
if@p2(...) S2
@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@
// likewise ignore it if there has been an intervening return
ret@p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if@p2(...) S2
@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
//
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/gma500/psb_drv.c |8 ++--
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 92e7e57..4eff0d6 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -326,12 +326,16 @@ static int psb_driver_load(struct drm_device *dev,
unsigned long flags)
goto out_err;
dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
- if (!dev_priv->mmu)
+ if (!dev_priv->mmu) {
+ ret = -ENOMEM;
goto out_err;
+ }
dev_priv->pf_pd = psb_mmu_alloc_pd(dev_priv->mmu, 1, 0);
- if (!dev_priv->pf_pd)
+ if (!dev_priv->pf_pd) {
+ ret = -ENOMEM;
goto out_err;
+ }
ret = psb_do_init(dev);
if (ret)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 7841970..58a00b5 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -703,6 +703,7 @@ static int omap_dmm_probe(struct platform_device *dev)
_dmm->refill_pa, GFP_KERNEL);
if (!omap_dmm->refill_va) {
dev_err(>dev, "could not allocate refill memory\n");
+ ret = -ENOMEM;
goto fail;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: usdhi6rol0: fix error return code
Propagate error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/mmc/host/usdhi6rol0.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
index 54b082b..99f894c 100644
--- a/drivers/mmc/host/usdhi6rol0.c
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -1734,8 +1734,10 @@ static int usdhi6_probe(struct platform_device *pdev)
}
host->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(host->clk))
+ if (IS_ERR(host->clk)) {
+ ret = PTR_ERR(host->clk);
goto e_free_mmc;
+ }
host->imclk = clk_get_rate(host->clk);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/11] Input: sur40: fix error return code
Propagate error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/input/touchscreen/sur40.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8be7b9b..3f11763 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -581,6 +581,7 @@ static int sur40_probe(struct usb_interface *interface,
sur40->alloc_ctx = vb2_dma_sg_init_ctx(sur40->dev);
if (IS_ERR(sur40->alloc_ctx)) {
dev_err(sur40->dev, "Can't allocate buffer context");
+ error = PTR_ERR(sur40->alloc_ctx);
goto err_unreg_v4l2;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/exynos: mic: fix error return code
Propagate error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/exynos/exynos_drm_mic.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 8994eab..ddf0b6c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -432,6 +432,7 @@ int exynos_mic_probe(struct platform_device *pdev)
"samsung,disp-syscon");
if (IS_ERR(mic->sysreg)) {
DRM_ERROR("mic: Failed to get system register.\n");
+ ret = PTR_ERR(mic->sysreg);
goto err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] soc: ti: knav_qmss_queue: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/soc/ti/knav_qmss_queue.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..822ead8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1768,6 +1768,7 @@ static int knav_queue_probe(struct platform_device *pdev)
regions = of_get_child_by_name(node, "descriptor-regions");
if (!regions) {
dev_err(dev, "descriptor-regions not specified\n");
+ ret = -ENODEV;
goto err;
}
ret = knav_queue_setup_regions(kdev, regions);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: davinci_emac: fix error return code
Propagate error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/ti/davinci_emac.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index aeebc0a..a21c77b 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -2004,8 +2004,10 @@ static int davinci_emac_probe(struct platform_device
*pdev)
if (res_ctrl) {
priv->ctrl_base =
devm_ioremap_resource(>dev, res_ctrl);
- if (IS_ERR(priv->ctrl_base))
+ if (IS_ERR(priv->ctrl_base)) {
+ rc = PTR_ERR(priv->ctrl_base);
goto no_pdata;
+ }
} else {
priv->ctrl_base = priv->remap_addr + pdata->ctrl_mod_reg_offset;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: xlp: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/gpio/gpio-xlp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-xlp.c b/drivers/gpio/gpio-xlp.c
index 9bdab72..e02499a 100644
--- a/drivers/gpio/gpio-xlp.c
+++ b/drivers/gpio/gpio-xlp.c
@@ -387,7 +387,7 @@ static int xlp_gpio_probe(struct platform_device *pdev)
irq_base = irq_alloc_descs(-1, XLP_GPIO_IRQ_BASE, gc->ngpio, 0);
if (irq_base < 0) {
dev_err(>dev, "Failed to allocate IRQ numbers\n");
- return err;
+ return -ENODEV;
}
err = gpiochip_add(gc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ah6: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
net/ipv6/ah6.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index ed7d4e3..0630a4d 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -577,8 +577,10 @@ static int ah6_input(struct xfrm_state *x, struct sk_buff
*skb)
work_iph = ah_alloc_tmp(ahash, nfrags + sglists, hdr_len +
ahp->icv_trunc_len + seqhi_len);
- if (!work_iph)
+ if (!work_iph) {
+ err = -ENOMEM;
goto out;
+ }
auth_data = ah_tmp_auth((u8 *)work_iph, hdr_len);
seqhi = (__be32 *)(auth_data + ahp->icv_trunc_len);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] fbdev: ssd1307fb: fix error return code
Propagate error code on failure. Also changed %ld to %d in dev_err to use
ret variable rather than putting two calls to PTR_ERR.
A simplified version of the semantic match that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/video/fbdev/ssd1307fb.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3e153c0..1611215 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -656,8 +656,9 @@ static int ssd1307fb_probe(struct i2c_client *client,
bl = backlight_device_register(bl_name, >dev, par,
_bl_ops, NULL);
if (IS_ERR(bl)) {
- dev_err(>dev, "unable to register backlight device:
%ld\n",
- PTR_ERR(bl));
+ ret = PTR_ERR(bl);
+ dev_err(>dev, "unable to register backlight device:
%d\n",
+ ret);
goto bl_init_error;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: omap: fix error return code
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/mmc/host/omap.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 70dcf07..b763b11 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1420,8 +1420,10 @@ static int mmc_omap_probe(struct platform_device *pdev)
host->reg_shift = (mmc_omap7xx() ? 1 : 2);
host->mmc_omap_wq = alloc_workqueue("mmc_omap", 0, 0);
- if (!host->mmc_omap_wq)
+ if (!host->mmc_omap_wq) {
+ ret = -ENOMEM;
goto err_plat_cleanup;
+ }
for (i = 0; i < pdata->nr_slots; i++) {
ret = mmc_omap_new_slot(host, i);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Moving more kernel data into highmem?
Hey, I remembered that there's an option to put third level page tables in highmem. This might be a stupid question, but is there a way to move more kernel data into highmem? For example, page directories, first level page tables? I even remember a few articles on lwn about how much space is taken up by struct page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LOAN OFFER OF ALL TYPES
Good day, PAUL FREDRICK FINANCE offer loans at 2% annual rate. Apply with amount needed, loan duration and phone number Via: :paulfredrickfinanceserv...@gmail.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/
[lkp] [sb_edac] 7d375bffa5:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 7d375bffa52477c1be7db5a5dda6582512c3 ("sb_edac: Fix support for
systems with two home agents per socket")
We found the following message in kernel log on a Sandy Bridge-EP machine.
[ 21.647493] EDAC sbridge: Couldn't find mci handler
[ 21.647505] EDAC sbridge: Couldn't find mci handler
Thanks,
Ying Huang
kmsg.xz
Description: application/xz
[lkp] [drm/i915] 3a03dfb057: [drm:stop_ring [i915]] *ERROR* render ring : timed out trying to stop ring
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 3a03dfb057d0ee5f3146ffe40179af3ed7e48213 ("drm/i915: Calculate vblank
timestamping constants before enabling vblank.")
[ 29.944531] [drm] Driver supports precise vblank timestamp query.
[ 29.954553] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 29.986458] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21:
Can't calculate constants, dotclock = 0!
[ 31.008632] [drm:stop_ring [i915]] *ERROR* render ring : timed out trying to
stop ring
[ 32.022144] [drm:stop_ring [i915]] *ERROR* render ring : timed out trying to
stop ring
[ 32.031521] [drm:init_ring_common [i915]] *ERROR* failed to set render ring
head to zero ctl 0001f001 head 0064 tail 00c0 start 00012000
[ 32.047317] [drm:i915_gem_init [i915]] *ERROR* Failed to initialize GPU,
declaring it wedged
[ 32.059922] fbcon: inteldrmfb (fb0) is primary device
[ 32.02] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 32.067027] input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Ying Huang
kmsg.xz
Description: application/xz
job.yaml
Description: Binary data
reproduce
Description: Binary data
[lkp] [fsnotify] 8f2f3eb59d: -4.0% will-it-scale.per_thread_ops
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 8f2f3eb59dff4ec538de55f2e0592fec85966aab ("fsnotify: fix oops in
fsnotify_clear_marks_by_group_flags()")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/test:
lkp-sbx04/will-it-scale/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/read1
commit:
447f6a95a9c80da7faaec3e66e656eab8f262640
8f2f3eb59dff4ec538de55f2e0592fec85966aab
447f6a95a9c80da7 8f2f3eb59dff4ec538de55f2e0
--
%stddev %change %stddev
\ |\
1844687 ± 0% -4.0%1770899 ± 0% will-it-scale.per_thread_ops
283.69 ± 0% +9.5% 310.64 ± 0% will-it-scale.time.user_time
4576 ± 3% -7.3% 4242 ± 6%
will-it-scale.time.voluntary_context_switches
7211 ± 10% +54.0% 11101 ± 18% cpuidle.C1E-SNB.usage
10636 ± 36% +69.3% 18003 ± 36% numa-meminfo.node1.Shmem
1.07 ± 4% -13.1% 0.93 ± 9%
perf-profile.cpu-cycles.selinux_file_permission.security_file_permission.rw_verify_area.vfs_read.sys_read
4576 ± 3% -7.3% 4242 ± 6% time.voluntary_context_switches
526.75 ±104% -94.2% 30.50 ± 98% numa-numastat.node1.other_node
1540 ± 35% -74.2% 398.00 ± 90% numa-numastat.node2.other_node
32344 ± 5% +7.4% 34722 ± 4% numa-vmstat.node0.numa_other
2658 ± 36% +69.3% 4500 ± 36% numa-vmstat.node1.nr_shmem
935792 ±136% +4247.3% 40682138 ±141%
latency_stats.avg.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
935792 ±136% +4247.3% 40682138 ±141%
latency_stats.max.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
935792 ±136% +4247.3% 40682138 ±141%
latency_stats.sum.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
12893 ± 2% -9.1% 11716 ± 1% slabinfo.kmalloc-192.active_objs
1653 ± 9% -10.3% 1483 ± 5% slabinfo.mnt_cache.active_objs
1653 ± 9% -10.3% 1483 ± 5% slabinfo.mnt_cache.num_objs
1.75 ± 47% -81.0% 0.33 ±141%
sched_debug.cfs_rq[10]:/.nr_spread_over
-343206 ±-27% -73.2% -91995 ±-170% sched_debug.cfs_rq[14]:/.spread0
533.25 ± 82% -81.5% 98.75 ± 42%
sched_debug.cfs_rq[18]:/.blocked_load_avg
541.75 ± 82% -81.3% 101.25 ± 41%
sched_debug.cfs_rq[18]:/.tg_load_contrib
-1217705 ± -5% -30.2%-850080 ±-15% sched_debug.cfs_rq[26]:/.spread0
89722 ± 9% +9.8% 98495 ± 10%
sched_debug.cfs_rq[32]:/.exec_clock
101180 ±132%+180.8% 284154 ± 30% sched_debug.cfs_rq[35]:/.spread0
37332 ±473%+725.2% 308082 ± 59% sched_debug.cfs_rq[38]:/.spread0
32054 ±502%+981.6% 346689 ± 39% sched_debug.cfs_rq[39]:/.spread0
1.00 ±100%+100.0% 2.00 ± 50%
sched_debug.cfs_rq[42]:/.nr_spread_over
-125980 ±-218%-307.1% 260875 ± 46% sched_debug.cfs_rq[42]:/.spread0
-111501 ±-102%-288.7% 210354 ± 94% sched_debug.cfs_rq[45]:/.spread0
-173363 ±-34%-221.0% 209775 ± 94% sched_debug.cfs_rq[47]:/.spread0
-302090 ±-43%-121.8% 65953 ±322% sched_debug.cfs_rq[4]:/.spread0
-490175 ±-18% -41.1%-288722 ±-31% sched_debug.cfs_rq[50]:/.spread0
-594948 ±-10% -59.7%-239840 ±-33% sched_debug.cfs_rq[51]:/.spread0
1.00 ±100% +6050.0% 61.50 ±141%
sched_debug.cfs_rq[53]:/.blocked_load_avg
10.50 ± 8%+614.3% 75.00 ±122%
sched_debug.cfs_rq[53]:/.tg_load_contrib
-596043 ±-10% -49.0%-304277 ±-36% sched_debug.cfs_rq[54]:/.spread0
10.00 ± 0% +2062.5% 216.25 ± 40%
sched_debug.cfs_rq[56]:/.tg_load_contrib
17.75 ±173% +1302.8% 249.00 ± 26%
sched_debug.cfs_rq[60]:/.blocked_load_avg
-809633 ± -9% -36.2%-516886 ±-23% sched_debug.cfs_rq[60]:/.spread0
28.00 ±109%+828.6% 260.00 ± 25%
sched_debug.cfs_rq[60]:/.tg_load_contrib
277.75 ± 95% -86.3% 38.00 ±171%
sched_debug.cfs_rq[7]:/.blocked_load_avg
293.25 ± 90% -81.8% 53.50 ±121%
sched_debug.cfs_rq[7]:/.tg_load_contrib
17.50 ± 2% -28.6% 12.50 ± 34% sched_debug.cpu#0.cpu_load[2]
17.00 ± 4% -25.0% 12.75 ± 35% sched_debug.cpu#0.cpu_load[3]
2907 ± 12%+195.9% 8603 ± 63% sched_debug.cpu#0.sched_goidle
16.50 ±
[lkp] [f2fs] 88a70a69c0: +49.4% fsmark.files_per_sec
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 88a70a69c088933011615fe26242e0335b012284 ("f2fs: fix wrong condition
check to trigger f2fs_sync_fs")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/iterations/nr_threads/disk/fs/filesize/test_size/sync_method/nr_directories/nr_files_per_directory:
nhm4/fsmark/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/1x/32t/1HDD/f2fs/16MB/60G/NoSync/16d/256fpd
commit:
cd52b6368f1301b55d0e484105c876930e443d83
88a70a69c088933011615fe26242e0335b012284
cd52b6368f1301b5 88a70a69c088933011615fe262
--
%stddev %change %stddev
\ |\
698894 ± 2% -10.7% 624267 ± 1% fsmark.app_overhead
6.43 ± 0% +49.4% 9.60 ± 0% fsmark.files_per_sec
496.30 ± 0% -3.7% 477.72 ± 0% fsmark.time.elapsed_time
496.30 ± 0% -3.7% 477.72 ± 0% fsmark.time.elapsed_time.max
58356 ± 9% -49.3% 29591 ± 7%
fsmark.time.involuntary_context_switches
11.75 ± 3% -14.9% 10.00 ± 0%
fsmark.time.percent_of_cpu_this_job_got
59.14 ± 0% -16.3% 49.50 ± 0% fsmark.time.system_time
609502 ± 0% -35.9% 390479 ± 0%
fsmark.time.voluntary_context_switches
2134 ± 5% -29.7% 1499 ± 6% uptime.idle
229046 ± 0% -13.3% 198655 ± 1% meminfo.Dirty
146785 ± 1% +57.8% 231574 ± 1% meminfo.Writeback
2034 ± 0% +10.0% 2238 ± 1% slabinfo.kmalloc-256.active_objs
448.00 ± 0% +23.1% 551.50 ± 1% slabinfo.kmalloc-4096.active_objs
482.25 ± 0% +21.6% 586.25 ± 1% slabinfo.kmalloc-4096.num_objs
24996 ± 0% -18.5% 20379 ± 1% softirqs.BLOCK
93299 ± 1% +21.1% 112999 ± 0% softirqs.SCHED
132179 ± 0% +18.6% 156829 ± 1% softirqs.TIMER
58356 ± 9% -49.3% 29591 ± 7% time.involuntary_context_switches
11.75 ± 3% -14.9% 10.00 ± 0% time.percent_of_cpu_this_job_got
59.14 ± 0% -16.3% 49.50 ± 0% time.system_time
609502 ± 0% -35.9% 390479 ± 0% time.voluntary_context_switches
126546 ± 0% +3.6% 131110 ± 0% vmstat.io.bo
15.25 ± 2%+103.3% 31.00 ± 0% vmstat.procs.b
23495 ± 0% +1.6% 23881 ± 0% vmstat.system.cs
10330 ± 0% +4.8% 10825 ± 0% vmstat.system.in
3.14 ± 3% -8.0% 2.89 ± 0% turbostat.%Busy
96.75 ± 3% -12.4% 84.75 ± 0% turbostat.Avg_MHz
12.01 ± 2% +12.6% 13.53 ± 4% turbostat.CPU%c1
40.58 ± 1% +73.6% 70.47 ± 0% turbostat.CPU%c3
44.27 ± 0% -70.4% 13.12 ± 3% turbostat.CPU%c6
1.506e+08 ± 2% -18.6% 1.225e+08 ± 5% cpuidle.C1-NHM.time
63432793 ± 2% +45.7% 92408180 ± 5% cpuidle.C1E-NHM.time
85526 ± 1% -27.4% 62121 ± 2% cpuidle.C1E-NHM.usage
1.024e+09 ± 0% +45.5% 1.49e+09 ± 1% cpuidle.C3-NHM.time
266717 ± 0% +43.9% 383733 ± 1% cpuidle.C3-NHM.usage
2.619e+09 ± 0% -22.9% 2.018e+09 ± 0% cpuidle.C6-NHM.time
194213 ± 2% -30.4% 135255 ± 1% cpuidle.C6-NHM.usage
155.50 ± 58% -91.9% 12.67 ± 73% proc-vmstat.allocstall
951.00 ± 5%+230.8% 3145 ± 1%
proc-vmstat.kswapd_high_wmark_hit_quickly
3011 ± 3% -31.6% 2060 ± 10%
proc-vmstat.kswapd_low_wmark_hit_quickly
57266 ± 0% -13.3% 49663 ± 1% proc-vmstat.nr_dirty
0.75 ±110% +13700.0% 103.50 ± 26%
proc-vmstat.nr_vmscan_immediate_reclaim
36690 ± 1% +57.8% 57885 ± 1% proc-vmstat.nr_writeback
4229 ± 1% +24.9% 5283 ± 3% proc-vmstat.pageoutrun
8779 ± 2% -45.8% 4755 ± 1% proc-vmstat.pgactivate
78067 ± 23% -97.8% 1738 ± 73% proc-vmstat.pgscan_direct_dma32
18409 ± 3% -32.8% 12373 ± 3%
sched_debug.cfs_rq[0]:/.min_vruntime
18497 ± 4% -18.9% 14995 ± 2%
sched_debug.cfs_rq[1]:/.min_vruntime
87.71 ±1609% +2889.8% 2622 ± 27% sched_debug.cfs_rq[1]:/.spread0
2068 ± 13% +39.3% 2880 ± 20%
sched_debug.cfs_rq[2]:/.avg->runnable_avg_sum
18322 ± 1% -27.5% 13284 ± 5%
sched_debug.cfs_rq[2]:/.min_vruntime
44.00 ± 13% +41.5% 62.25 ± 20%
sched_debug.cfs_rq[2]:/.tg_runnable_contrib
2260 ± 17% +69.9% 3840 ± 39%
sched_debug.cfs_rq[3]:/.avg->runnable_avg_sum
18810 ± 2% -27.2% 13703 ± 4%
sched_debug.cfs_rq[3]:/.min_vruntime
48.50 ± 16% +70.1% 82.50 ± 39%
sched_debug.cfs_rq[3]:/.tg_runnable_contrib
4839 ± 5% -43.8% 2718 ± 14% sched_debug.cfs_rq[4]:/.exec_clock
15393 ± 2% -55.7% 6817
[PATCH 01/14] RDS: restore return value in rds_cmsg_rdma_args()
In rds_cmsg_rdma_args() 'ret' is used by rds_pin_pages() which returns
number of pinned pages on success. And the same value is returned to the
caller of rds_cmsg_rdma_args() on success which is not intended.
Commit f4a3fc03c1d7 ("RDS: Clean up error handling in rds_cmsg_rdma_args")
removed the 'ret = 0' line which broke RDS RDMA mode.
Fix it by restoring the return value on rds_pin_pages() success
keeping the clean-up in place.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/rdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 40084d8..6401b50 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -658,6 +658,8 @@ int rds_cmsg_rdma_args(struct rds_sock *rs, struct
rds_message *rm,
ret = rds_pin_pages(iov->addr, nr, pages, !op->op_write);
if (ret < 0)
goto out;
+ else
+ ret = 0;
rdsdebug("RDS: nr_bytes %u nr %u iov->bytes %llu iov->addr
%llx\n",
nr_bytes, nr, iov->bytes, iov->addr);
--
1.9.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 08/14] RDS: Mark message mapped before transmit
rds_send_xmit() marks the rds message map flag after
xmit_[rdma/atomic]() which is clearly wrong. We need
to maintain the ownership between transport and rds.
Also take care of error path.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index dbdf907..96ae38d 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -282,26 +282,34 @@ restart:
/* The transport either sends the whole rdma or none of it */
if (rm->rdma.op_active && !conn->c_xmit_rdma_sent) {
rm->m_final_op = >rdma;
+ /* The transport owns the mapped memory for now.
+* You can't unmap it while it's on the send queue
+*/
+ set_bit(RDS_MSG_MAPPED, >m_flags);
ret = conn->c_trans->xmit_rdma(conn, >rdma);
- if (ret)
+ if (ret) {
+ clear_bit(RDS_MSG_MAPPED, >m_flags);
+ wake_up_interruptible(>m_flush_wait);
break;
+ }
conn->c_xmit_rdma_sent = 1;
- /* The transport owns the mapped memory for now.
-* You can't unmap it while it's on the send queue */
- set_bit(RDS_MSG_MAPPED, >m_flags);
}
if (rm->atomic.op_active && !conn->c_xmit_atomic_sent) {
rm->m_final_op = >atomic;
+ /* The transport owns the mapped memory for now.
+* You can't unmap it while it's on the send queue
+*/
+ set_bit(RDS_MSG_MAPPED, >m_flags);
ret = conn->c_trans->xmit_atomic(conn, >atomic);
- if (ret)
+ if (ret) {
+ clear_bit(RDS_MSG_MAPPED, >m_flags);
+ wake_up_interruptible(>m_flush_wait);
break;
+ }
conn->c_xmit_atomic_sent = 1;
- /* The transport owns the mapped memory for now.
-* You can't unmap it while it's on the send queue */
- set_bit(RDS_MSG_MAPPED, >m_flags);
}
/*
--
1.9.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 02/14] RDS: always free recv frag as we free its ring entry
We were still seeing rare occurrences of the WARN_ON(recv->r_frag) which
indicates that the recv refill path was finding allocated frags in ring
entries that were marked free. These were usually followed by OOM crashes.
They only seem to be occurring in the presence of completion errors and
connection resets.
This patch ensures that we free the frag as we mark the ring entry free.
This should stop the refill path from finding allocated frags in ring
entries that were marked free.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_recv.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index cac5b45..2a6a75c 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -982,10 +982,17 @@ static inline void rds_poll_cq(struct rds_ib_connection
*ic,
}
/*
-* It's very important that we only free this ring entry if
we've truly
-* freed the resources allocated to the entry. The refilling
path can
-* leak if we don't.
+* rds_ib_process_recv() doesn't always consume the frag, and
+* we might not have called it at all if the wc didn't indicate
+* success. We already unmapped the frag's pages, though, and
+* the following rds_ib_ring_free() call tells the refill path
+* that it will not find an allocated frag here. Make sure we
+* keep that promise by freeing a frag that's still on the ring.
*/
+ if (recv->r_frag) {
+ rds_ib_frag_free(ic, recv->r_frag);
+ recv->r_frag = NULL;
+ }
rds_ib_ring_free(>i_recv_ring, 1);
}
}
--
1.9.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 05/14] RDS: make sure we post recv buffers
If we get an ENOMEM during rds_ib_recv_refill, we might never come
back and refill again later. Patch makes sure to kick krdsd into
helping out.
To achieve this we add RDS_RECV_REFILL flag and update in the refill
path based on that so that at least some therad will keep posting
receive buffers.
Since krdsd and softirq both might race for refill, we decide to
schedule on work queue based on ring_low instead of ring_empty.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/connection.c | 2 ++
net/rds/ib.h | 2 +-
net/rds/ib_cm.c | 2 +-
net/rds/ib_recv.c| 58 ++--
net/rds/rds.h| 1 +
5 files changed, 57 insertions(+), 8 deletions(-)
diff --git a/net/rds/connection.c b/net/rds/connection.c
index da6da57..67405c1 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -297,6 +297,8 @@ void rds_conn_shutdown(struct rds_connection *conn)
wait_event(conn->c_waitq,
!test_bit(RDS_IN_XMIT, >c_flags));
+ wait_event(conn->c_waitq,
+ !test_bit(RDS_RECV_REFILL, >c_flags));
conn->c_trans->conn_shutdown(conn);
rds_conn_reset(conn);
diff --git a/net/rds/ib.h b/net/rds/ib.h
index 86d88ec..6422c52 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -320,7 +320,7 @@ void rds_ib_recv_exit(void);
int rds_ib_recv(struct rds_connection *conn);
int rds_ib_recv_alloc_caches(struct rds_ib_connection *ic);
void rds_ib_recv_free_caches(struct rds_ib_connection *ic);
-void rds_ib_recv_refill(struct rds_connection *conn, int prefill);
+void rds_ib_recv_refill(struct rds_connection *conn, int prefill, gfp_t gfp);
void rds_ib_inc_free(struct rds_incoming *inc);
int rds_ib_inc_copy_to_user(struct rds_incoming *inc, struct iov_iter *to);
void rds_ib_recv_cq_comp_handler(struct ib_cq *cq, void *context);
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 8b40d3c..cb78da1 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -135,7 +135,7 @@ void rds_ib_cm_connect_complete(struct rds_connection
*conn, struct rdma_cm_even
rds_ib_recv_init_ring(ic);
/* Post receive buffers - as a side effect, this will update
* the posted credit count. */
- rds_ib_recv_refill(conn, 1);
+ rds_ib_recv_refill(conn, 1, GFP_KERNEL);
/* Tune RNR behavior */
rds_ib_tune_rnr(ic, _attr);
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index 2a6a75c..3afdcbd 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -297,7 +297,7 @@ static struct rds_page_frag *rds_ib_refill_one_frag(struct
rds_ib_connection *ic
}
static int rds_ib_recv_refill_one(struct rds_connection *conn,
- struct rds_ib_recv_work *recv, int prefill)
+ struct rds_ib_recv_work *recv, gfp_t gfp)
{
struct rds_ib_connection *ic = conn->c_transport_data;
struct ib_sge *sge;
@@ -305,7 +305,7 @@ static int rds_ib_recv_refill_one(struct rds_connection
*conn,
gfp_t slab_mask = GFP_NOWAIT;
gfp_t page_mask = GFP_NOWAIT;
- if (prefill) {
+ if (gfp & __GFP_WAIT) {
slab_mask = GFP_KERNEL;
page_mask = GFP_HIGHUSER;
}
@@ -347,6 +347,24 @@ out:
return ret;
}
+static int acquire_refill(struct rds_connection *conn)
+{
+ return test_and_set_bit(RDS_RECV_REFILL, >c_flags) == 0;
+}
+
+static void release_refill(struct rds_connection *conn)
+{
+ clear_bit(RDS_RECV_REFILL, >c_flags);
+
+ /* We don't use wait_on_bit()/wake_up_bit() because our waking is in a
+* hot path and finding waiters is very rare. We don't want to walk
+* the system-wide hashed waitqueue buckets in the fast path only to
+* almost never find waiters.
+*/
+ if (waitqueue_active(>c_waitq))
+ wake_up_all(>c_waitq);
+}
+
/*
* This tries to allocate and post unused work requests after making sure that
* they have all the allocations they need to queue received fragments into
@@ -354,15 +372,23 @@ out:
*
* -1 is returned if posting fails due to temporary resource exhaustion.
*/
-void rds_ib_recv_refill(struct rds_connection *conn, int prefill)
+void rds_ib_recv_refill(struct rds_connection *conn, int prefill, gfp_t gfp)
{
struct rds_ib_connection *ic = conn->c_transport_data;
struct rds_ib_recv_work *recv;
struct ib_recv_wr *failed_wr;
unsigned int posted = 0;
int ret = 0;
+ int can_wait = gfp & __GFP_WAIT;
u32 pos;
+ /* the goal here is to just make sure that someone, somewhere
+* is posting buffers. If we can't get the refill lock,
+* let them do their thing
+*/
+ if (!acquire_refill(conn))
+ return;
+
while ((prefill || rds_conn_up(conn)) &&
[PATCH 06/14] RDS: check for congestion updates during rds_send_xmit
Ensure we don't keep sending the data if the link is congested.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index e9430f5..dbdf907 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -411,7 +411,8 @@ over_batch:
*/
if (ret == 0) {
smp_mb();
- if (!list_empty(>c_send_queue) &&
+ if ((test_bit(0, >c_map_queued) ||
+!list_empty(>c_send_queue)) &&
send_gen == conn->c_send_gen) {
rds_stats_inc(s_send_lock_queue_raced);
goto restart;
--
1.9.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 11/14] RDS: Don't destroy the rdma id until after we're done using it
From: Santosh Shilimkar During connection resets, we are destroying the rdma id too soon. We can't destroy it when it is still in use. So lets move rdma_destroy_id() after we clear the rings. Reviewed-by: Ajaykumar Hotchandani Signed-off-by: Santosh Shilimkar Signed-off-by: Santosh Shilimkar --- net/rds/ib_cm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c index cb78da1..0443af7 100644 --- a/net/rds/ib_cm.c +++ b/net/rds/ib_cm.c @@ -646,7 +646,6 @@ void rds_ib_conn_shutdown(struct rds_connection *conn) ib_destroy_cq(ic->i_send_cq); if (ic->i_recv_cq) ib_destroy_cq(ic->i_recv_cq); - rdma_destroy_id(ic->i_cm_id); /* then free the resources that ib callbacks use */ if (ic->i_send_hdrs) @@ -672,6 +671,8 @@ void rds_ib_conn_shutdown(struct rds_connection *conn) if (ic->i_recvs) rds_ib_recv_clear_ring(ic); + rdma_destroy_id(ic->i_cm_id); + /* * Move connection back to the nodev list. */ -- 1.9.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 10/14] RDS: Fix assertion level from fatal to warning
Fix the asserion level since its not fatal and can be hit
in normal execution paths. There is no need to take the
system down.
We keep the WARN_ON() to detect the condition if we get
here with bad pages.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_rdma.c | 2 +-
net/rds/rdma.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index e49c956..7b7aac8 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -490,7 +490,7 @@ static void __rds_ib_teardown_mr(struct rds_ib_mr *ibmr)
/* FIXME we need a way to tell a r/w MR
* from a r/o MR */
- BUG_ON(irqs_disabled());
+ WARN_ON(!page->mapping && irqs_disabled());
set_page_dirty(page);
put_page(page);
}
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 6401b50..c1df9b1 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -451,7 +451,7 @@ void rds_rdma_free_op(struct rm_rdma_op *ro)
* is the case for a RDMA_READ which copies from remote
* to local memory */
if (!ro->op_write) {
- BUG_ON(irqs_disabled());
+ WARN_ON(!page->mapping && irqs_disabled());
set_page_dirty(page);
}
put_page(page);
--
1.9.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 03/14] RDS: destroy the ib state earlier during shutdown
Destroy ib state early during shutdown. Otherwise we can get callbacks after the QP isn't really able to handle them. Reviewed-by: Ajaykumar Hotchandani Signed-off-by: Santosh Shilimkar Signed-off-by: Santosh Shilimkar --- net/rds/ib_cm.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c index 0da2a45..8b40d3c 100644 --- a/net/rds/ib_cm.c +++ b/net/rds/ib_cm.c @@ -639,6 +639,16 @@ void rds_ib_conn_shutdown(struct rds_connection *conn) (atomic_read(>i_signaled_sends) == 0)); tasklet_kill(>i_recv_tasklet); + /* first destroy the ib state that generates callbacks */ + if (ic->i_cm_id->qp) + rdma_destroy_qp(ic->i_cm_id); + if (ic->i_send_cq) + ib_destroy_cq(ic->i_send_cq); + if (ic->i_recv_cq) + ib_destroy_cq(ic->i_recv_cq); + rdma_destroy_id(ic->i_cm_id); + + /* then free the resources that ib callbacks use */ if (ic->i_send_hdrs) ib_dma_free_coherent(dev, ic->i_send_ring.w_nr * @@ -662,14 +672,6 @@ void rds_ib_conn_shutdown(struct rds_connection *conn) if (ic->i_recvs) rds_ib_recv_clear_ring(ic); - if (ic->i_cm_id->qp) - rdma_destroy_qp(ic->i_cm_id); - if (ic->i_send_cq) - ib_destroy_cq(ic->i_send_cq); - if (ic->i_recv_cq) - ib_destroy_cq(ic->i_recv_cq); - rdma_destroy_id(ic->i_cm_id); - /* * Move connection back to the nodev list. */ -- 1.9.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 04/14] RDS: don't update ip address tables if the address hasn't changed
If the ip address tables hasn't changed, there is no need to remove
them only to be added back again.
Lets fix it.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_rdma.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 657ba9f..e49c956 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -151,12 +151,17 @@ int rds_ib_update_ipaddr(struct rds_ib_device *rds_ibdev,
__be32 ipaddr)
struct rds_ib_device *rds_ibdev_old;
rds_ibdev_old = rds_ib_get_device(ipaddr);
- if (rds_ibdev_old) {
+ if (!rds_ibdev_old)
+ return rds_ib_add_ipaddr(rds_ibdev, ipaddr);
+
+ if (rds_ibdev_old != rds_ibdev) {
rds_ib_remove_ipaddr(rds_ibdev_old, ipaddr);
rds_ib_dev_put(rds_ibdev_old);
+ return rds_ib_add_ipaddr(rds_ibdev, ipaddr);
}
+ rds_ib_dev_put(rds_ibdev_old);
- return rds_ib_add_ipaddr(rds_ibdev, ipaddr);
+ return 0;
}
void rds_ib_add_conn(struct rds_ib_device *rds_ibdev, struct rds_connection
*conn)
--
1.9.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 09/14] RDS: Make sure we do a signaled send for large-send
WR(Work Requests )always generate a WC(Work Completion) with
signaled send. Default RDS ib code is setup for un-signaled
completion. Since RDS connction is persistent, we can end up
sending the data even after large-send when the remote end is
not active(for any reason).
By doing a signaled send at least once per large-send,
we can at least detect the problem in work completion
handler there by avoiding sending more data to
inactive remote.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_send.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index 5d0a704..c576ebe 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -709,6 +709,11 @@ int rds_ib_xmit(struct rds_connection *conn, struct
rds_message *rm,
if (scat == >data.op_sg[rm->data.op_count]) {
prev->s_op = ic->i_data_op;
prev->s_wr.send_flags |= IB_SEND_SOLICITED;
+ if (!(prev->s_wr.send_flags & IB_SEND_SIGNALED)) {
+ ic->i_unsignaled_wrs = rds_ib_sysctl_max_unsig_wrs;
+ prev->s_wr.send_flags |= IB_SEND_SIGNALED;
+ nr_sig++;
+ }
ic->i_data_op = NULL;
}
--
1.9.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 07/14] RDS: add a sock_destruct callback debug aid
This helps to detect the accidental processes/apps trying to destroy
the RDS socket which they are sharing with other processes/apps.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/af_rds.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index 896834c..a2f28a6 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -438,6 +438,14 @@ static const struct proto_ops rds_proto_ops = {
.sendpage = sock_no_sendpage,
};
+static void rds_sock_destruct(struct sock *sk)
+{
+ struct rds_sock *rs = rds_sk_to_rs(sk);
+
+ WARN_ON((>rs_item != rs->rs_item.next ||
+>rs_item != rs->rs_item.prev));
+}
+
static int __rds_create(struct socket *sock, struct sock *sk, int protocol)
{
struct rds_sock *rs;
@@ -445,6 +453,7 @@ static int __rds_create(struct socket *sock, struct sock
*sk, int protocol)
sock_init_data(sock, sk);
sock->ops = _proto_ops;
sk->sk_protocol = protocol;
+ sk->sk_destruct = rds_sock_destruct;
rs = rds_sk_to_rs(sk);
spin_lock_init(>rs_lock);
--
1.9.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 13/14] RDS: return EMSGSIZE for oversize requests before processing/queueing
From: Mukesh Kacker
rds_send_queue_rm() allows for the "current datagram" being queued
to exceed SO_SNDBUF thresholds by checking bytes queued without
counting in length of current datagram. (Since sk_sndbuf is set
to twice requested SO_SNDBUF value as a kernel heuristic this
is usually fine!)
If this "current datagram" squeezing past the threshold is itself
many times the size of the sk_sndbuf threshold itself then even
twice the SO_SNDBUF does not save us and it gets queued but
cannot be transmitted. Threads block and deadlock and device
becomes unusable. The check for this datagram not exceeding
SNDBUF thresholds (EMSGSIZE) is not done on this datagram as
that check is only done if queueing attempt fails.
(Datagrams that follow this datagram fail queueing attempts, go
through the check and eventually trip EMSGSIZE error but zero
length datagrams silently fail!)
This fix moves the check for datagrams exceeding SNDBUF limits
before any processing or queueing is attempted and returns EMSGSIZE
early in the rds_sndmsg() code. This change also ensures that all
datagrams get checked for exceeding SNDBUF/sk_sndbuf size limits
and the large datagrams that exceed those limits do not get to
rds_send_queue_rm() code for processing.
Signed-off-by: Mukesh Kacker
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index b0fe412..c2667bf 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -1015,6 +1015,11 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg,
size_t payload_len)
goto out;
}
+ if (payload_len > rds_sk_sndbuf(rs)) {
+ ret = -EMSGSIZE;
+ goto out;
+ }
+
/* size of rm including all sgs */
ret = rds_rm_size(msg, payload_len);
if (ret < 0)
@@ -1086,11 +1091,7 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg,
size_t payload_len)
while (!rds_send_queue_rm(rs, conn, rm, rs->rs_bound_port,
dport, )) {
rds_stats_inc(s_send_queue_full);
- /* XXX make sure this is reasonable */
- if (payload_len > rds_sk_sndbuf(rs)) {
- ret = -EMSGSIZE;
- goto out;
- }
+
if (nonblock) {
ret = -EAGAIN;
goto out;
--
1.9.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 14/14] RDS: check for valid cm_id before initiating connection
Connection could have been dropped while the route is being resolved
so check for valid cm_id before initiating the connection.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/rdma_transport.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
index 2082408..b9b40af 100644
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -34,6 +34,7 @@
#include
#include "rdma_transport.h"
+#include "ib.h"
static struct rdma_cm_id *rds_rdma_listen_id;
@@ -82,8 +83,18 @@ int rds_rdma_cm_event_handler(struct rdma_cm_id *cm_id,
break;
case RDMA_CM_EVENT_ROUTE_RESOLVED:
- /* XXX worry about racing with listen acceptance */
- ret = trans->cm_initiate_connect(cm_id);
+ /* Connection could have been dropped so make sure the
+* cm_id is valid before proceeding
+*/
+ if (conn) {
+ struct rds_ib_connection *ibic;
+
+ ibic = conn->c_transport_data;
+ if (ibic && ibic->i_cm_id == cm_id)
+ ret = trans->cm_initiate_connect(cm_id);
+ else
+ rds_conn_drop(conn);
+ }
break;
case RDMA_CM_EVENT_ESTABLISHED:
--
1.9.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 00/14] RDS: Assorted bug fixes
We would like to improve RDS upstream support and in that context, I started playing with it. But run into number of issues including as basic is RDS IB RDMA doesn't work. As part of the debug, I ended up creating the $subject series which has bunch of assorted fixes. At least with this series I can run RDS IB RDMA and other tests successfully. Some of these fixes have been done by Chris Meson, Andy Grover and Zach Brown while at Oracle. There are still more kinks with FMR and error handling and I plan to address them in a follow up series. Series generated against Linus's master(v4.2-rc-7) but also applies against next-next cleanly. Its tested on Oracle hardware with IB fabric for both bcopy as well as RDMA mode. I don't have access to iWARP hardware so any testing help on iWARP hardware appreciated. Mukesh Kacker (1): RDS: return EMSGSIZE for oversize requests before processing/queueing Santosh Shilimkar (13): RDS: restore return value in rds_cmsg_rdma_args() RDS: always free recv frag as we free its ring entry RDS: destroy the ib state earlier during shutdown RDS: don't update ip address tables if the address hasn't changed RDS: make sure we post recv buffers RDS: check for congestion updates during rds_send_xmit RDS: add a sock_destruct callback debug aid RDS: Mark message mapped before transmit RDS: Make sure we do a signaled send for large-send RDS: Fix assertion level from fatal to warning RDS: Don't destroy the rdma id until after we're done using it RDS: make sure rds_send_drop_to properly takes the m_rs_lock RDS: check for valid cm_id before initiating connection net/rds/af_rds.c | 9 ++ net/rds/connection.c | 2 ++ net/rds/ib.h | 2 +- net/rds/ib_cm.c | 17 +++- net/rds/ib_rdma.c| 11 ++-- net/rds/ib_recv.c| 71 ++-- net/rds/ib_send.c| 5 net/rds/rdma.c | 4 ++- net/rds/rdma_transport.c | 15 -- net/rds/rds.h| 1 + net/rds/send.c | 54 ++-- 11 files changed, 153 insertions(+), 38 deletions(-) Regards, Santosh -- 1.9.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 12/14] RDS: make sure rds_send_drop_to properly takes the m_rs_lock
rds_send_drop_to() is used during socket tear down to find all the
messages on the socket and flush them . It can race with the
acking code unless it takes the m_rs_lock on each and every message.
This plugs a hole where we didn't take m_rs_lock on any message that
didn't have the RDS_MSG_ON_CONN set. Taking m_rs_lock avoids
double frees and other memory corruptions as the ack code trusts
the message m_rs pointer on a socket that had actually been freed.
We must take m_rs_lock to access m_rs. Because of lock nesting and
rs access, we also need to acquire rs_lock.
Reviewed-by: Ajaykumar Hotchandani
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 96ae38d..b0fe412 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -778,8 +778,22 @@ void rds_send_drop_to(struct rds_sock *rs, struct
sockaddr_in *dest)
while (!list_empty()) {
rm = list_entry(list.next, struct rds_message, m_sock_item);
list_del_init(>m_sock_item);
-
rds_message_wait(rm);
+
+ /* just in case the code above skipped this message
+* because RDS_MSG_ON_CONN wasn't set, run it again here
+* taking m_rs_lock is the only thing that keeps us
+* from racing with ack processing.
+*/
+ spin_lock_irqsave(>m_rs_lock, flags);
+
+ spin_lock(>rs_lock);
+ __rds_send_complete(rs, rm, RDS_RDMA_CANCELED);
+ spin_unlock(>rs_lock);
+
+ rm->m_rs = NULL;
+ spin_unlock_irqrestore(>m_rs_lock, flags);
+
rds_message_put(rm);
}
}
--
1.9.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/
[ebeam PATCH v2 2/2] input: misc: New USB eBeam input driver
Add new USB input driver for Luidia's eBeam devices.
Currently supported (tested) :
- eBeam classic projection and edge projection models
- Nec interactive solution NP01Wi1 & NP01Wi2 accessories.
Notable stuff :
- 13 sysfs custom files : 9 values for the transformation matrix,
4 for xy ranges and a calibration trigger.
- need userspace gui tool for calibration (ebeam.tuxfamily.org)
Signed-off-by: Yann Cantin
---
Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++
drivers/input/misc/ebeam.c | 759 +++
2 files changed, 812 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam
create mode 100644 drivers/input/misc/ebeam.c
diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam
b/Documentation/ABI/testing/sysfs-driver-ebeam
new file mode 100644
index 000..3a663e8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ebeam
@@ -0,0 +1,53 @@
+What:
/sys/bus/usb/drivers/ebeam/-:./min_x
+
/sys/bus/usb/drivers/ebeam/-:./min_y
+
/sys/bus/usb/drivers/ebeam/-:./max_x
+
/sys/bus/usb/drivers/ebeam/-:./max_y
+Date: Jul 2015
+Kernel Version:4.1
+Contact: yann.can...@laposte.net
+ linux-...@vger.kernel.org
+Description:
+ Reading from these files return the actually used range values
of
+ the reported coordinates.
+ Writing to these files preset these range values.
+ See below for the calibration procedure.
+
+What:
/sys/bus/usb/drivers/ebeam/-:./h[1..9]
+Date: Jul 2015
+Kernel Version:4.1
+Contact: yann.can...@laposte.net
+ linux-...@vger.kernel.org
+Description:
+ Reading from these files return the 3x3 transformation matrix
elements
+ actually used, in row-major.
+ Writing to these files preset these elements values.
+ See below for the calibration procedure.
+
+What:
/sys/bus/usb/drivers/ebeam/-:./calibrated
+Date: Jul 2015
+Kernel Version:4.1
+Contact: yann.can...@laposte.net
+ linux-...@vger.kernel.org
+Description:
+ Reading from this file :
+ - Return 0 if the driver is in "un-calibrated" mode : it
actually send
+ raw coordinates in the device's internal coordinates system.
+ - Return 1 if the driver is in "calibrated" mode : it send
computed coordinates
+ that (hopefully) matches the screen's coordinates system.
+ Writing 1 to this file enable the "calibrated" mode, 0 reset
the driver in
+ "un-calibrated" mode.
+
+Calibration procedure :
+
+When loaded, the driver is in "un-calibrated" mode : it send device's raw
coordinates
+in the [0..65535]x[0..65535] range, the transformation matrix is the identity.
+
+A calibration program have to compute a homography transformation matrix that
convert
+the device's raw coordinates to the matching screen's ones.
+It then write to the appropriate sysfs files the computed values, pre-setting
the
+driver's parameters : xy range, and the matrix's elements.
+When all values are passed, it write 1 to the calibrated sysfs file to enable
the "calibrated" mode.
+
+Warning : The parameters aren't used until 1 is writen to the calibrated sysfs
file.
+
+These files can also be accessed via /sys/class/input/inputXX/device/
diff --git a/drivers/input/misc/ebeam.c b/drivers/input/misc/ebeam.c
new file mode 100644
index 000..e7b9f3e
--- /dev/null
+++ b/drivers/input/misc/ebeam.c
@@ -0,0 +1,759 @@
+/**
+ *
+ * eBeam driver
+ *
+ * Copyright (C) 2012-2015 Yann Cantin (yann.can...@laposte.net)
+ *
+ * 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.
+ *
+ * based on
+ *
+ * usbtouchscreen.c by Daniel Ritz
+ * aiptek.c (sysfs/settings) by Chris Atenasio
+ * Bryan W. Headley
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_AUTHOR "Yann Cantin "
+#define DRIVER_DESC"USB eBeam Driver"
+
+/* Common values for eBeam devices */
+#define REPT_SIZE 8 /* packet size*/
+#define MIN_RAW_X 0 /* raw coordinates ranges */
+#define MAX_RAW_X 0x
+#define MIN_RAW_Y 0
+#define MAX_RAW_Y 0x
+
+#define EBEAM_BTN_TIP 0x1 /* tip*/
+#define EBEAM_BTN_LIT 0x2 /* little */
+#define EBEAM_BTN_BIG 0x4 /* big*/
+
+/* ebeam settings */
+struct ebeam_settings {
[ebeam PATCH v2 1/2] hid: Blacklist eBeam devices
Add known eBeam devices usb ids.
Prevent hid-generic to take over these devices. This breaks Luidia's
proprietary application suite.
Signed-off-by: Yann Cantin
---
drivers/hid/hid-core.c | 6 ++
drivers/hid/hid-ids.h | 6 ++
drivers/input/misc/Kconfig | 22 ++
drivers/input/misc/Makefile | 1 +
4 files changed, 35 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e6fce23..b5edb0f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2270,6 +2270,12 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
+#if defined(CONFIG_INPUT_EBEAM_USB)
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB1) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB1) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB2) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY,
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b3b225b..aa6f2da 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -306,6 +306,12 @@
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7 0x73f7
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001
+#define USB_VENDOR_ID_EFI 0x2650
+#define USB_DEVICE_ID_EFI_EBEAM_USB1 0x1311
+#define USB_DEVICE_ID_EFI_EBEAM_USB2 0x1315
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB10x1313
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB20x1320
+
#define USB_VENDOR_ID_ELAN 0x04f3
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B0x009b
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..22c46a4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -103,6 +103,28 @@ config INPUT_E3X0_BUTTON
To compile this driver as a module, choose M here: the
module will be called e3x0_button.
+config INPUT_EBEAM_USB
+ tristate "USB eBeam driver"
+ depends on USB_ARCH_HAS_HCD
+ select USB
+ help
+ Say Y here if you have a USB eBeam pointing device and want to
+ use it without any proprietary user space tools.
+
+ Have a look at
[ebeam PATCH v2 0/2] Add a new USB eBeam input driver
Hi, New USB input driver for eBeam devices. Notable stuff : - need userspace gui tool for calibration (ebeam.tuxfamily.org) - This driver breaks Luidia's proprietary application suite. Patch 1 to blacklist the devices for hid generic-usb. Patch 2 is the actual driver. Changes : RFC https://lkml.org/lkml/2015/7/20/634 : Use DEVICE_ATTR_RW() RFC https://lkml.org/lkml/2015/7/21/107 : move usb id definitions out of ebeam.c RFC https://lkml.org/lkml/2015/7/20/657 : Fix ABI documentation Thanks for your help. Yann Cantin (2): hid: Blacklist eBeam devices input: misc: New USB eBeam input driver Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++ drivers/hid/hid-core.c | 6 + drivers/hid/hid-ids.h| 6 + drivers/input/misc/Kconfig | 22 + drivers/input/misc/Makefile | 1 + drivers/input/misc/ebeam.c | 759 +++ 6 files changed, 847 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam create mode 100644 drivers/input/misc/ebeam.c -- 2.3.8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mips: Fix console output for Fulong2e system
On Thu, Aug 06, 2015 at 10:57:16PM -0700, Guenter Roeck wrote:
> Commit 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
> made the number of UARTs dynamic if LEFI_FIRMWARE_INTERFACE is configured.
> Unfortunately, it did not initialize the number of UARTs if
> LEFI_FIRMWARE_INTERFACE is not configured. As a result, the Fulong2e
> system has no console.
>
> Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
> Cc: Huacai Chen
> Signed-off-by: Guenter Roeck
Hello Ralf,
please let me know if anything is wrong with this patch.
Should I resend with Huacai Chen's Ack and capital MIPS in the subject line ?
Thanks,
Guenter
> ---
> Never mind my earlier e-mail, I figured it out.
> Should be a candidate for stable (v3.19+, ie v4.1 in practice).
>
> arch/mips/loongson64/common/env.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/mips/loongson64/common/env.c
> b/arch/mips/loongson64/common/env.c
> index f6c44dd332e2..d6d07ad56180 100644
> --- a/arch/mips/loongson64/common/env.c
> +++ b/arch/mips/loongson64/common/env.c
> @@ -64,6 +64,9 @@ void __init prom_init_env(void)
> }
> if (memsize == 0)
> memsize = 256;
> +
> + loongson_sysconf.nr_uarts = 1;
> +
> pr_info("memsize=%u, highmemsize=%u\n", memsize, highmemsize);
> #else
> struct boot_params *boot_p;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bcachefs - a general purpose COW filesystem
Hi Kent, On Thu, 2015-08-20 at 21:25 -0800, Kent Overstreet wrote: > For those who haven't kept up with bcache, the bcache codebase has been > evolving/metastasizing into a full blown, general purpose posix filesystem - a > modern COW filesystem with checksumming, compression, multiple devices, > caching, > and eventually snapshots and all kinds of other nifty features. > > "Yet another new filesystem? Why?" > > Well, years ago (going back to when I was still at Google), I and the other > people working on bcache realized that what we were working on was, almost by > accident, a good chunk of the functionality of a full blown filesystem - and > there was a really clean and elegant design to be had there if we took it and > ran with it. And a fast one - the main goal of bcachefs to match ext4 and xfs > on > performance and reliability, but with the features of btrfs/zfs. > > > PLANNED FEATURES: > - snapshots (might start on this soon) > - erasure coding What erasure coding scheme(s) do you like to use? > - native support for SMR drives, raw flash How do you imagine SMR drives support? How do you feel about libzbc [1] using for SMR drives support? I am not very familiar with bcachefs architecture yet. But I suppose that maybe libzbc model can be useful for SMR drives support on bcachefs side. Anyway, it makes sense to discuss proper model. How do you imagine raw flash support in bcachefs architecture? Frankly speaking, I am implementing NAND flash oriented file system. But this project is proprietary yet and I can't share any details. However, currently, I've implemented NAND flash related approaches in my file system only. So, maybe, it make sense to consider some joint variant of bcachefs and implementation on my side for NAND flash support. I need to be more familiar with bcachefs architecture for such decision. But, unfortunately, I suspect that it can be not so easy to support raw flash for bcachefs. Of course, I can be wrong. [1] https://github.com/hgst/libzbc Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] hrtimer: Fix hang seen if tick_init_highres() failed
On Sat, 22 Aug 2015 01:10:47 -0700
Guenter Roeck wrote:
> Commit 75e3b37d0598 ("hrtimer: Drop return code of hrtimer_switch_to_hres()")
> drops the return code of hrtimer_switch_to_hres(). While doing so, it also
> drops the return statement itself on failure. This may cause a system hang.
> Seen when running arm:multi_v7_defconfig in qemu with devicetree file
> vexpress-v2p-ca9.
>
> Fixes: 75e3b37d0598 ("hrtimer: Drop return code of hrtimer_switch_to_hres()")
> Cc: Luiz Capitulino
> Signed-off-by: Guenter Roeck
Thanks for catching it Guenter!
Reviewed-by: Luiz Capitulino
> ---
> kernel/time/hrtimer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 5c4fe50e47d3..457a373e2181 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -695,6 +695,7 @@ static void hrtimer_switch_to_hres(void)
> if (tick_init_highres()) {
> printk(KERN_WARNING "Could not switch to high resolution "
> "mode on CPU %d\n", base->cpu);
> + return;
> }
> base->hres_active = 1;
> hrtimer_resolution = HIGH_RES_NSEC;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] firmware_class: few small code shifts
On Fri, Aug 21, 2015 at 10:38:24PM -0700, Greg KH wrote: > On Fri, Aug 21, 2015 at 11:23:03PM +0200, Luis R. Rodriguez wrote: > > On Tue, Aug 04, 2015 at 03:00:00PM -0700, Luis R. Rodriguez wrote: > > > From: "Luis R. Rodriguez" > > > > > > Ming, Greg, > > > > > > this patch set consists of a few small code shifts which would make > > > it easier to add extensible firmware API code, and later firmware > > > signing support. This patch set is being sent out separately as it > > > does not contain any controversial changes. It should also help > > > with readibility of the code. > > > > > > I'll be Cc'ing linux-doc, linux-security-module, and keyring folks as the > > > next patch sets would start slowly diving into the topic of firmware > > > signing > > > and extending documentation, and those patches will depend on this set. > > > > > > There is a superfluous else branch on patch #3, its not needed because of > > > the goto statement but we leave that in place to make patch #4 easier to > > > read. > > > > > > David Howells (2): > > > firmware: fold successful fw read early > > > firmware: generalize reading file contents as a helper > > > > > > Luis R. Rodriguez (2): > > > firmware: generalize "firmware" as "system data" helpers > > > firmware: move completing fw into a helper > > > > Ming, Greg, > > > > Please let me know if there are any issues with this series. > > It's too late for 4.3 at the moment, and my first impulse is you are > just painting the bikeshed by changing some printk names, so I don't > like that, This series doesn't address the actual sysdata helper changes which make the firmware API easly extensible, it just paves the path for it, so because of that what you describe is correct but only in lack of sight of the other RFC patch I posted [0]. [0] http://1438730036-22913-1-git-send-email-mcg...@do-not-panic.com > but I'll review it in full after 4.3-rc1 is out, can't do > anything until then. Sure. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl
On Sat, Aug 22, 2015 at 10:33:48PM +0200, Thomas Gleixner wrote:
> > @@ -196,19 +197,31 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int
> > cmd, unsigned long arg)
> > break;
> > }
> > pct = >ts[0];
> > - for (i = 0; i < sysoff->n_samples; i++) {
> > - getnstimeofday64();
> > + if (ptp->info->getsynctime64 && sysoff->n_samples == 1 &&
>
> The number of samples should be irrelevant for this sampling method.
Chris had send me a preview of this before he posted, so I can explain
that test for one sample.
User space requests N (1 to 25) samples of the two clocks. The kernel
is supposed to deliver that many samples. This has always been the
documented behavior. From ptp_clock.h:
struct ptp_sys_offset {
unsigned int n_samples; /* Desired number of measurements. */
unsigned int rsv[3];/* Reserved for future use. */
/*
* Array of interleaved system/phc time stamps. The kernel
* will provide 2*n_samples + 1 time stamps, with the last
* one as a system time stamp.
*/
struct ptp_clock_time ts[2 * PTP_MAX_SAMPLES + 1];
};
So the kernel cannot simply change n_samples to 1.
I would prefer to have a new system call that compares any two posix
clock_t, but that is of course more work.
Allowing n_samples=1 as a special case is a kind of overloading of the
ioctl to support the new capability. At least it preserves the
behavior of the interface from the user's perspective.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ping: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
Ping!
On Fri, Aug 14, 2015 at 03:46:14AM +0200, Frederic Weisbecker wrote:
> From: Vatika Harlalka
>
> The problem addressed in this patch is about affining unpinned timers.
> Adaptive or Full Dynticks CPUs are currently disturbed by unnecessary
> jitter due to firing of such timers on them.
>
> This patch will affine timers to online CPUs which are not full dynticks
> in NOHZ_FULL configured systems. It should not introduce overhead in
> nohz full off case due to static keys.
>
> Reviewed-by: Preeti U Murthy
> Signed-off by: Vatika Harlalka
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Christoph Lameter
> Cc: Thomas Gleixner
> Cc: Paul E. McKenney
> Cc: Chris Metcalf
> Signed-off-by: Frederic Weisbecker
> ---
> include/linux/tick.h | 9 -
> kernel/sched/core.c | 7 +--
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 3741ba1..51e6493 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -143,13 +143,20 @@ static inline void tick_nohz_full_add_cpus_to(struct
> cpumask *mask)
> if (tick_nohz_full_enabled())
> cpumask_or(mask, mask, tick_nohz_full_mask);
> }
> -
> +static inline int housekeeping_any_cpu(void)
> +{
> + return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> +}
> extern void __tick_nohz_full_check(void);
> extern void tick_nohz_full_kick(void);
> extern void tick_nohz_full_kick_cpu(int cpu);
> extern void tick_nohz_full_kick_all(void);
> extern void __tick_nohz_task_switch(struct task_struct *tsk);
> #else
> +static inline int housekeeping_any_cpu(void)
> +{
> + return smp_processor_id();
> +}
> static inline bool tick_nohz_full_enabled(void) { return false; }
> static inline bool tick_nohz_full_cpu(int cpu) { return false; }
> static inline void tick_nohz_full_add_cpus_to(struct cpumask *mask) { }
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9917c96..4fd42e4 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -623,18 +623,21 @@ int get_nohz_timer_target(void)
> int i, cpu = smp_processor_id();
> struct sched_domain *sd;
>
> - if (!idle_cpu(cpu))
> + if (!idle_cpu(cpu) && is_housekeeping_cpu(cpu))
> return cpu;
>
> rcu_read_lock();
> for_each_domain(cpu, sd) {
> for_each_cpu(i, sched_domain_span(sd)) {
> - if (!idle_cpu(i)) {
> + if (!idle_cpu(i) && is_housekeeping_cpu(cpu)) {
> cpu = i;
> goto unlock;
> }
> }
> }
> +
> + if (!is_housekeeping_cpu(cpu))
> + cpu = housekeeping_any_cpu();
> unlock:
> rcu_read_unlock();
> return cpu;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] Enabling hardware supported PTP system/device crosstimestamping
On Fri, 21 Aug 2015, Christopher S. Hall wrote:
> From: Christopher Hall
>
> Add getsynctime() PTP device callback to cross timestamp system device
> clock using ART translation depends on platform being >= SPT
> and having ART
>
> getsynctime() reads ART (TSC-derived)/device cross timestamp and
> converts to realtime/device time reporting cross timestamp to
> PTP driver
See patch 1/4
> index 25a0ad5..228f3f3 100644
> --- a/drivers/net/ethernet/intel/e1000e/ptp.c
> +++ b/drivers/net/ethernet/intel/e1000e/ptp.c
> @@ -25,6 +25,8 @@
> */
>
> #include "e1000.h"
> +#include
> +#include
The usual way to order includes is:
#include
#include
#include "e1000.h"
> +/**
> + * e1000e_phc_getsynctime - Reads the current time from the hardware clock
> and
> + * correlated system time
> + * @ptp: ptp clock structure
> + * @devts: timespec structure to hold the current device time value
> + * @systs: timespec structure to hold the current system time value
> + *
> + * Read device and system (ART) clock simultaneously and return the correct
> + * clock values in ns after converting into a struct timespec.
> + **/
> +static int e1000e_phc_getsynctime(struct ptp_clock_info *ptp,
> + struct timespec64 *devts,
> + struct timespec64 *systs)
> +{
> + struct e1000_adapter *adapter = container_of(ptp, struct e1000_adapter,
> + ptp_clock_info);
> + unsigned long flags;
> + u32 remainder;
> + struct correlated_ts art_correlated_ts;
> + u64 device_time;
> + int ret;
> +
> + art_correlated_ts.get_ts = e1000e_phc_get_ts;
> + art_correlated_ts.private = adapter;
> + ret = get_correlated_timestamp(_correlated_ts,
> +_timestamper);
Pointless line break
> + if (ret != 0)
> + goto bail;
What's the purpose of this goto?
if (ret)
return ret;
is completely sufficient.
> +
> + systs->tv_sec =
> + div_u64_rem(art_correlated_ts.system_real.tv64,
> + NSEC_PER_SEC, );
> + systs->tv_nsec = remainder;
ktime_to_timespec64() perhaps?
And please move that conversion to the ptp ioctl
> + spin_lock_irqsave(>systim_lock, flags);
> + device_time = timecounter_cyc2time(>tc,
> +art_correlated_ts.device_ts);
> + /* CPU must have ART and GBe must be from Sunrise Point or greater */
> + if (hw->mac.type < e1000_pch_spt || !cpu_has_art)
> + adapter->ptp_clock_info.getsynctime64 = NULL;
We do it the other way round. We leave the default NULL and update it
if we detect the feature.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl
On Fri, 21 Aug 2015, Christopher S. Hall wrote:
> From: Christopher Hall
>
> This patch allows system and device time ("cross-timestamp") to be
> performed by the driver. Currently, the cross-timestamping is performed
> in the PTP_SYS_OFFSET ioctl. The PTP clock driver reads gettimeofday()
> and the gettime64() callback provided by the driver. The cross-timestamp
> is best effort where the latency between the capture of system time
> (getnstimeofday()) and the device time (driver callback) may be
> significant.
>
> This patch adds an additional callback getsynctime64(). Which will be
> called when the driver is able to perform a more accurate, implementation
> specific cross-timestamping. For example, future network devices that
> implement PCIE PTM will be able to precisely correlate the device clock
> with the system clock with virtually zero latency between captures.
> This added callback can be used by the driver to expose this functionality.
>
> The callback, getsynctime64(), will only be called when defined and
> n_samples == 1 because the driver returns only 1 cross-timestamp where
> multiple samples cannot be chained together.
>
> This patch also adds to the capabilities ioctl (PTP_CLOCK_GETCAPS),
> allowing applications to query whether or not drivers implement the
> getsynctime callback, providing more precise cross timestamping.
That looks close to a proper changelog. A few nitpicks though.
Please avoid 'This patch does ...' phrases. We already know that this
is a patch.
> Commit Details:
Please get rid of this. It's useless noise.
> Added additional callback to ptp_clock_info:
>
> * getsynctime64()
> @@ -196,19 +197,31 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int
> cmd, unsigned long arg)
> break;
> }
> pct = >ts[0];
> - for (i = 0; i < sysoff->n_samples; i++) {
> - getnstimeofday64();
> + if (ptp->info->getsynctime64 && sysoff->n_samples == 1 &&
The number of samples should be irrelevant for this sampling method.
> + ptp->info->getsynctime64(ptp->info, , ) == 0) {
Why is this function taking struct timespec64 pointers? Just so every
driver which implements the callback needs to convert from u64 to
struct timespec64? That's simply wrong. Use u64 for both and do the
conversion in the ioctl.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for suspend
On Fri 2015-08-21 19:53:34, Chen Yu wrote:
> A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
> that, after resuming from S3, CPU is working at a low speed.
> After investigation, it is found that, BIOS has modified the value
> of THERM_CONTROL register during S3, changes it from 0 to 0x10,
> while the latter means CPU can only get 25% of the Duty Cycle,
> and this caused the problem.
>
> Simple scenario to reproduce:
> 1.Boot up system
> 2.Get MSR with address 0x19a, it should output 0
> 3.Put system into sleep, then wake up
> 4.Get MSR with address 0x19a, it should output 0(actual it outputs 0x10)
>
> Although this is a BIOS issue, it would be more robust for linux to deal
> with this situation. This patch fixes this issue by introducing a framework
> for saving/restoring specify MSR registers(THERM_CONTROL in this case)
> on suspend/resume.
>
> When user finds a problematic platform that requires save/restore MSRs,
> he can simply add quirk in msr_save_dmi_table, and customizes MSR
> registers in quirk callback, for example:
>
> unsigned int msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
>
> and system ensures that, once resumed from suspend, these MSR indicated
> by IDs will be restored to their original values before suspend.
>
> Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
> common code path. And because the MSR ids specified by user might not be
> available or readable in any situation, we use rdmsrl_safe to safely
> save these MSR registers.
>
> Tested-by: Marcin Kaszewski
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] Added ART correlated clocksource and ART CPU feature
On Fri, 21 Aug 2015, Christopher S. Hall wrote:
> Add detect_art() call to early TSC initialization which reads ART->TSC
> numerator/denominator and sets CPU feature if present
>
> Add convert_art_to_tsc() function performing conversion ART to TSC
>
> Add art_timestamp referencing art_to_tsc() and clocksource_tsc enabling
> driver conversion of ART to TSC
That changelog needs a rewrite. See patch 1/4
> @@ -352,6 +352,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
> #define cpu_has_de boot_cpu_has(X86_FEATURE_DE)
> #define cpu_has_pse boot_cpu_has(X86_FEATURE_PSE)
> #define cpu_has_tsc boot_cpu_has(X86_FEATURE_TSC)
> +#define cpu_has_art boot_cpu_has(X86_FEATURE_ART)
Please do not add more cpu_has macros. There is nothing wrong to write
boot_cpu_has(X86_FEATURE_ART) in the code.
> +#define ART_CPUID_LEAF (0x15)
> +#define ART_MIN_DENOMINATOR (2)
#define ART_CPUID_LEAF 0x15
#define ART_MIN_DENOMINATOR2
Why is the minimum denominator 2? That wants a comment.
> +static u32 art_to_tsc_numerator;
> +static u32 art_to_tsc_denominator;
Both want to be read_mostly
> +/*
> + * If ART is present detect the numberator:denominator to convert to TSC
> + */
> +void detect_art(void)
> +{
> + unsigned int unused[2];
> +
> + if (boot_cpu_data.cpuid_level >= ART_CPUID_LEAF) {
> + cpuid(ART_CPUID_LEAF, _to_tsc_denominator,
> + _to_tsc_numerator, unused, unused+1);
> +
> + if (art_to_tsc_denominator >= ART_MIN_DENOMINATOR) {
> + set_cpu_cap(_cpu_data, X86_FEATURE_ART);
> + }
No parentheses around one liners please.
> + }
> +}
> +
> static int __init cpufreq_tsc(void)
> {
> if (!cpu_has_tsc)
> return 0;
> +
> + detect_art();
> +
> if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
> return 0;
> cpufreq_register_notifier(_cpufreq_notifier_block,
> @@ -1059,6 +1085,32 @@ int unsynchronized_tsc(void)
> return 0;
> }
>
> +/*
> + * Convert ART to TSC given numerator/denominator found in detect_art()
> + */
> +static u64 convert_art_to_tsc(struct correlated_cs *cs, u64 cycles)
> +{
> + u64 tmp, res;
> +
> + switch (art_to_tsc_denominator) {
> + default:
> + res = (cycles / art_to_tsc_denominator) * art_to_tsc_numerator;
> + tmp = (cycles % art_to_tsc_denominator) * art_to_tsc_numerator;
> + res += tmp / art_to_tsc_denominator;
> + break;
> + case 2:
> +res = (cycles >> 1) * art_to_tsc_numerator;
> +tmp = (cycles & 0x1) * art_to_tsc_numerator;
> +res += tmp >> 1;
> +break;
Is it really worth do do this optimization? And if we do it we
shouldn't special case it for 2. You can check at ART detection time
whether the denominator is a power of two and have a flag which
selects a div/mod base or a shift based conversion.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource
On Fri, 21 Aug 2015, Christopher S. Hall wrote:
> Add struct correlated_cs with pointer to original clocksource and
> function pointer to convert correlated clocksource to the original
>
> Add get_correlated_timestamp() function which given specific correlated_cs
> and correlated_ts convert correlated counter value to system time
This is not a proper changelog.
1) The subject line lacks a subsystem prefix
timekeeping:
Is the proper choice here
2) The subject line should be short and precise
timekeeping: Add mechanism to gather correlated timestamps
Might be an informative one.
3) The changelog itself should describe the reason why we want this
change, the purpose of the change etc.
Add foo
Add bar
Is pointless because we can see that from the patch itself.
What the patch cannot not explain is the WHY. That's what the
changelog is for.
4) You dropped the authorship
The proper way to do this is to add a 'FROM: author' at the top of
the changelog body.
As I wrote the patch, so I give you a changelog along with it:
<---
Subject: timekeeping: Add mechanism to gather correlated timestamps
From: Thomas Gleixner
Modern Intel hardware provides the so called Always Running Timer
(ART). The TSC which is usually used for timekeeping is derived from
ART and runs with a fixed frequency ratio to it. ART is routed to
devices and allows to take atomic timestamp samples from the device
clock and the ART. One use case is PTP timestamps on network cards. We
want to utilize this feature as it allows us to better correlate the
PTP timestamp to the system time.
In order to gather precise timestamps we need to make sure that the
conversion from ART to TSC and the following conversion from TSC to
clock realtime happens synchronized with the ongoing timekeeping
updates. Otherwise we might convert an ART timestamp from point A in
time with the conversion factors of point B in time. These conversion
factors can differ due to NTP/PTP frequency adjustments and therefor
the resulting clock realtime timestamp would be slightly off, which is
contrary to the whole purpose of synchronized hardware timestamps.
Provide data structures which describe the correlation between two
clocksources and a function to gather correlated and convert
timestamps from a device. The function is as any other timekeeping
function protected against current timekeeper updates via the
timekeeper sequence lock. It calls the device function to gather the
hardware timestamps and converts them to clock real time and clock
monotonic raw.
Signed-off-by: Thomas Gleixner
>
Can you see the difference?
> Signed-off-by: Christopher S. Hall
> ---
> include/linux/clocksource.h | 33 +++
> include/linux/timekeeping.h | 4 +++
> kernel/time/timekeeping.c | 65
> +
> 3 files changed, 102 insertions(+)
>
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index 278dd27..4bedadb 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -258,4 +258,37 @@ void acpi_generic_timer_init(void);
> static inline void acpi_generic_timer_init(void) { }
> #endif
>
> +/*
> + * struct correlated_cs - Descriptor for a clocksource correlated to another
> + * clocksource
Don't believe checkpatch here. KernelDoc requires that this is one
line, 80 char limit or not.
> /**
> + * get_correlated_timestamp - Get a correlated timestamp
> + *
Lacks the parameter documentation:
* @crt: Pointer to a correlated timestamp structure which provides
* the device specific timestamp function and is used to store
* the raw and the correlated timestamps.
* @crs: Pointer to a correlated clocksource structure which describes
* the correlated clocksource and provides a conversion function
* to the timekeeping clocksource
> + return 0;
> +}
> +EXPORT_SYMBOL(get_correlated_timestamp);
EXPORT_SYMBOL_GPL please.
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: [PATCHv3 0/5] Fix compound_head() race
On Thu, 20 Aug 2015, Andrew Morton wrote: > On Thu, 20 Aug 2015 15:31:07 +0300 "Kirill A. Shutemov" > wrote: > > > On Wed, Aug 19, 2015 at 12:21:41PM +0300, Kirill A. Shutemov wrote: > > > Here's my attempt on fixing recently discovered race in compound_head(). > > > It should make compound_head() reliable in all contexts. > > > > > > The patchset is against Linus' tree. Let me know if it need to be rebased > > > onto different baseline. > > > > > > It's expected to have conflicts with my page-flags patchset and probably > > > should be applied before it. > > > > > > v3: > > >- Fix build without hugetlb; > > >- Drop page->first_page; > > >- Update comment for free_compound_page(); > > >- Use 'unsigned int' for page order; > > > > > > v2: Per Hugh's suggestion page->compound_head is moved into third double > > > word. This way we can avoid memory overhead which v1 had in some > > > cases. > > > > > > This place in struct page is rather overloaded. More testing is > > > required to make sure we don't collide with anyone. > > > > Andrew, can we have the patchset applied, if nobody has objections? > > I've been hoping to hear from Hugh and I wasn't planning on processing > these before the 4.2 release. I think this patchset is very good, in a variety of different ways. Fixes a tricky race, deletes more code than it adds, shrinks kernel text, deletes tricky functions relying on barriers, frees up a page flag bit, removes a discrepancy between configs, is really neat in how PageTail is necessarily false on all lru and lru-candidate pages, probably more. Good job. Yes, I did think the compound destructor enum stuff over-engineered, and would have preferred just direct calls to free_compound_page() or free_huge_page() myself. But when I tried to make a patch on top to do that, even when I left PageHuge out-of-line (which had certainly not been my intention), it still generated more kernel text than Kirill's enum version (maybe his "- 1" in compound_head works better in some places than masking out 3, I didn't study); so let's forget about that. I've not actually run and tested with it, but I shall be pleased when it gets in to mmotm, and will do so then. As to whether it answers my doubts about his patch-flags patchset already in mmotm (not your question here, Andrew, but Kirill's in another of these mails): I'd say that it greatly reduces my doubts, but does not entirely set me at ease with the bloat. This set here gives us a compound_head() that is safe to tuck inside PageFlags ops in that set there: that doesn't worry me any more. And the bloat is reduced enough that I don't think it should be allowed to block Kirill's progress. But I can't shake off the idea that someone somewhere (0day perf results? Mel on an __spree?) is going to need to shave away some of these hidden and rarely needed compound_head() calls one day. Take __activate_page() in mm/swap.c as an example, something that begins with a bold PageLRU && !PageActive && !PageUnevictable. That function contains six sequences of the form mov 0x20(%rdi),%rax; test $0x1,%al; je over_next; sub $0x1,%rax. Five of which I expect could be avoided if we just did a compound_head() conversion on entry. I suppose any branch predictor will do a fine job with the last five: am I just too old-fashioned to be thinking we should (have the ability to) eliminate them completely? I'm not saying that we need to convert __activate_page, or anything else, at this time; but I do think we shall want diet versions of at least the simple PageFlags tests themselves (we should already be sparing with the atomic ones), and need to establish convention now for what the diet versions of PageFlags will be called. Would __PageFlag be good enough? Could we say that __SetPageFlag and __ClearPageFlag omit the compound_head() - we already have to think carefully when applying those? 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: [PATCH -next] parisc: Define ioremap_uc and ioremap_wc
ping ... the problem fixed with this patch still affects next-20150821.
Guenter
On Fri, Jul 31, 2015 at 07:34:46PM -0700, Guenter Roeck wrote:
> Commit 3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole
> with strong UC") introduces calls to ioremap_wc and ioremap_uc. This
> causes build failures with parisc:allmodconfig. Map the missing
> functions to ioremap_nocache.
>
> Fixes: 3cc2dac5be3f ("drivers/video/fbdev/atyfb:
> Replace MTRR UC hole with strong UC")
> Cc: Luis R. Rodriguez
> Cc: Paul Gortmaker
> Signed-off-by: Guenter Roeck
> ---
> arch/parisc/include/asm/io.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
> index 8cd0abf28ffb..1a16f1d1075f 100644
> --- a/arch/parisc/include/asm/io.h
> +++ b/arch/parisc/include/asm/io.h
> @@ -137,6 +137,8 @@ static inline void __iomem * ioremap(unsigned long
> offset, unsigned long size)
> return __ioremap(offset, size, _PAGE_NO_CACHE);
> }
> #define ioremap_nocache(off, sz) ioremap((off), (sz))
> +#define ioremap_wc ioremap_nocache
> +#define ioremap_uc ioremap_nocache
>
> extern void iounmap(const volatile void __iomem *addr);
>
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] rtc: drop unused ret variable orphaned by misc_deregister becoming void
In commit f368ed6088ae9c1fbe1c897bb5f215ce5e63fa1e ("char: make
misc_deregister a void function") this ret variable became unused
which now generates a compile warning. Get rid of it.
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: rtc-li...@googlegroups.com
Cc: Greg Kroah-Hartman
Signed-off-by: Paul Gortmaker
---
drivers/rtc/rtc-ds1374.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 7067232ba507..742ac67eb702 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -663,9 +663,8 @@ static int ds1374_probe(struct i2c_client *client,
static int ds1374_remove(struct i2c_client *client)
{
struct ds1374 *ds1374 = i2c_get_clientdata(client);
-#ifdef CONFIG_RTC_DRV_DS1374_WDT
- int res;
+#ifdef CONFIG_RTC_DRV_DS1374_WDT
misc_deregister(_miscdev);
ds1374_miscdev.parent = NULL;
unregister_reboot_notifier(_wdt_notifier);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns
On 08/22/2015 10:54 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> +/* fcmovCC and f(u)comi(p) are enabled if CPUID(1).EDX(15) "cmov" is set */
>> +
>> static FUNC const st_instr_table[64] = {
>> -fadd__, fld_i_, __BAD__, __BAD__, fadd_i, ffree_, faddp_, _df_c0_,
>> -fmul__, fxch_i, __BAD__, __BAD__, fmul_i, _dd_c8_, fmulp_, _df_c8_,
>> -fcom_st, fp_nop, __BAD__, __BAD__, _dc_d0_, fst_i_, _de_d0_, _df_d0_,
>> -fcompst, _d9_d8_, __BAD__, __BAD__, _dc_d8_, fstp_i, fcompp, _df_d8_,
>> +fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_,
>> _df_c0_,
>> +fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_, fmulp_,
>> _df_c8_,
>> +fcom_st, fp_nop, fcmovbe, fcmovnbe, _dc_d0_, fst_i_, _de_d0_,
>> _df_d0_,
>> +fcompst, _d9_d8_, fcmovu, fcmovnu, _dc_d8_, fstp_i, fcompp,
>> _df_d8_,
>> fsub__, FPU_etc, __BAD__, finit_, fsubri, fucom_, fsubrp, fstsw_,
>> -fsubr_, fconst, fucompp, __BAD__, fsub_i, fucomp, fsubp_, __BAD__,
>> -fdiv__, FPU_triga, __BAD__, __BAD__, fdivri, __BAD__, fdivrp, __BAD__,
>> +fsubr_, fconst, fucompp, fucomi_, fsub_i, fucomp, fsubp_,
>> fucomip,
>> +fdiv__, FPU_triga, __BAD__, fcomi_, fdivri, __BAD__, fdivrp, fcomip,
>> fdivr_, FPU_trigb, __BAD__, __BAD__, fdiv_i, __BAD__, fdivp_, __BAD__,
>> };
>
> So the problem is that you did not give an FPU register encoding type table
> entry
> for the new opcodes:
>
> static u_char const type_table[64] = {
> _REGI_, _NONE_, _null_, _null_, _REGIi, _REGi_, _REGIp, _REGi_,
> _REGI_, _REGIn, _null_, _null_, _REGIi, _REGI_, _REGIp, _REGI_,
> _REGIc, _NONE_, _null_, _null_, _REGIc, _REG0_, _REGIc, _REG0_,
> _REGIc, _REG0_, _null_, _null_, _REGIc, _REG0_, _REGIc, _REG0_,
> _REGI_, _NONE_, _null_, _NONE_, _REGIi, _REGIc, _REGIp, _NONE_,
> _REGI_, _NONE_, _REGIc, _null_, _REGIi, _REGIc, _REGIp, _null_,
> _REGI_, _NONE_, _null_, _null_, _REGIi, _null_, _REGIp, _null_,
> _REGI_, _NONE_, _null_, _null_, _REGIi, _null_, _REGIp, _null_
> };
>
> Those _null_ entries must be filled in as well.
>
> For FUCOMI[P] it's _REGIc I think, so I tried that - and the patch below on
> top of
> yours made those instructions appear to work - only to be caught in an MMX op:
>
> 0xb75eb3fb : movd %ebp,%mm0
>
>
>
> :-/
>
> Arguably the way I tested it, user-space libraries see SSE and MMX
> capabilities:
>
> flags : vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat
> pse36 clflush mmx sse2 ht syscall nx mmxext lm 3dnowext 3dnow rep_good pni
> lahf_lm
> cmp_legacy 3dnowprl...
>
> So I'll first turn those CPUID bits off, to (hopefully) not confuse
> user-space.
>
> Thanks,
>
> Ingo
>
> >
>
> arch/x86/math-emu/fpu_entry.c | 82
> ++-
> 1 file changed, 27 insertions(+), 55 deletions(-)
>
> diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c
> index d20c8f8420e2..4d91c0fc6bc3 100644
> --- a/arch/x86/math-emu/fpu_entry.c
> +++ b/arch/x86/math-emu/fpu_entry.c
> @@ -40,12 +40,10 @@
>
> #define __BAD__ FPU_illegal /* Illegal on an 80486, causes SIGILL */
>
> -#ifndef NO_UNDOC_CODE/* Un-documented FPU op-codes supported
> by default. */
> -
> -/* WARNING: These codes are not documented by Intel in their 80486 manual
> +/* WARNING: These codes are not all documented by Intel in their 80486 manual
> and may not work on FPU clones or later Intel FPUs. */
>
> -/* Changes to support the un-doc codes provided by Linus Torvalds. */
> +/* Changes to support the un-documented instructions provided by Linus
> Torvalds. */
>
> #define _d9_d8_ fstp_i /* unofficial code (19) */
> #define _dc_d0_ fcom_st /* unofficial code (14) */
> @@ -60,31 +58,24 @@
> /* fcmovCC and f(u)comi(p) are enabled if CPUID(1).EDX(15) "cmov" is set */
>
> static FUNC const st_instr_table[64] = {
> - fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_,
> _df_c0_,
> - fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_, fmulp_,
> _df_c8_,
> - fcom_st, fp_nop, fcmovbe, fcmovnbe, _dc_d0_, fst_i_, _de_d0_,
> _df_d0_,
> - fcompst, _d9_d8_, fcmovu, fcmovnu, _dc_d8_, fstp_i, fcompp,
> _df_d8_,
> - fsub__, FPU_etc, __BAD__, finit_, fsubri, fucom_, fsubrp, fstsw_,
> - fsubr_, fconst, fucompp, fucomi_, fsub_i, fucomp, fsubp_,
> fucomip,
> - fdiv__, FPU_triga, __BAD__, fcomi_, fdivri, __BAD__, fdivrp, fcomip,
> - fdivr_, FPU_trigb, __BAD__, __BAD__, fdiv_i, __BAD__, fdivp_, __BAD__,
> +/* 0x00 */ fadd__, fld_i_, fcmovb, fcmovnb,
> +/* 0x04 */ fadd_i, ffree_, faddp_, _df_c0_,
> +/* 0x08 */ fmul__, fxch_i, fcmove,
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Hello, Paul. On Fri, Aug 21, 2015 at 12:26:30PM -0700, Paul Turner wrote: ... > A very concrete example of the above is a virtual machine in which you > want to guarantee scheduling for the vCPU threads which must schedule > beside many hypervisor support threads. A hierarchy is the only way > to fix the ratio at which these compete. Just to learn more, what sort of hypervisor support threads are we talking about? They would have to consume considerable amount of cpu cycles for problems like this to be relevant and be dynamic in numbers in a way which letting them competing against vcpus makes sense. Do IO helpers meet these criteria? > An example that's not the cpu controller is that we use cpusets to > expose to applications their "shared" and "private" cores. (These > sets are dynamic based on what is coscheduled on a given machine.) Can you please go into more details with these? > > Why would you assume that threads of a process wouldn't want to > > configure it ever? How is this different from CPU affinity? > > In general cache and CPU behave differently. Generally for it to make > sense between threads in a process they would have to have wholly > disjoint memory, at which point the only sane long-term implementation > is separate processes and the management moves up a level anyway. > > That said, there are surely cases in which it might be convenient to > use at a per-thread level to correct a specific performance anomaly. > But at that point, you have certainly reached the level of hammer that > you can coordinate with an external daemon if necessary. So, I'm not super familiar with all the use cases but the whole cache allocation thing is almost by nature a specific niche thing and I feel pretty reluctant to blow off per-thread usages as too niche to worry about. > > I don't follow what you're trying to way with the above paragraph. > > Are you still talking about CAT? If so, that use case isn't the only > > one. I'm pretty sure there are people who would want to configure > > cache allocation at thread level. > > I'm not agreeing with you that "in cgroups" means "must be usable by > applications within that hierarchy". A cgroup subsystem used as a > partitioning API only by system management daemons is entirely > reasonable. CAT is a reasonable example of this. I see. The same argument. I don't think CAT just being system management thing makes sense. > > So, this is a trade-off we're consciously making. If there are > > common-enough use cases which require jumping across different cgroup > > domains, we'll try to figure out a way to accomodate those but by > > default migration is a very cold and expensive path. > > The core here was the need for allowing sub-process migration. I'm > not sure I follow the performance trade-off argument; haven't we > historically seen the opposite? That migration has been a slow-path > without optimizations and people pushing to make it faster? This > seems a hard generalization to make for something that's inherently > tied to a particular controller. It isn't something tied to a particular controller. Some controllers may get impacted less by than others but there's an inherent connection between how dynamic an association is and how expensive the locking around it needs to be and we need to set up basic behavior and usage conventions so that different controllers are designed and implemented assuming similar usage patterns; otherwise, we end up with the chaotic shit show that we have had where everything behaves differently and nobody knows what's the right way to do things and we end up locked into weird requirements which some controller induced for no good reason but cause significant pain on use cases which actually matter. > I don't care if we try turning that dial back to assume it's a cold > path once more, only that it's supported. It has always been a cold path and I'm not saying this is gonna be noticeably worse in the future but usages like bouncing threads on request-by-request basis are and will be clearly worse than bouncing to threads which are already in the target domain. > >> > A forwarding /proc/thread_self/cgroup accessor, or similar, would be > >> > another > >> > way to address some of these issues. > > > > That sounds horrible to me. What if the process wants to do RMW a > > config? > > Locking within a process is easy. It's not contained in the process at all. What if an external entity decides to migrate the process into another cgroup inbetween? > > What if the permissions are different after an intervening > > migration? > > This is a side-effect of migration not being properly supported. > > > What if the sub-hierarchy no longer exists or has been > > replaced by a hierarchy with the same topology but actualy is a > > different one? > > The easy answer is that: Only a process should be managing its > sub-hierarchy. That's the nice thing about hierarchies. cgroupfs is a horrible place
Re: [PATCH] lib: scatterlist: add sg splitting function
Robert Jarzmik writes: ...zip... top posting in [1] ... zip ... Hi Andrew, There was no review for a couple of weeks I'm afraid on this patch. Could I know what I can do to push it up ? And another question : do you want another patch to add a MAINTAINERS entry for this sg_split ? Cheers. -- Robert [1] The posted patch > Sometimes a scatter-gather has to be split into several chunks, or sub > scatter lists. This happens for example if a scatter list will be > handled by multiple DMA channels, each one filling a part of it. > > A concrete example comes with the media V4L2 API, where the scatter list > is allocated from userspace to hold an image, regardless of the > knowledge of how many DMAs will fill it : > - in a simple RGB565 case, one DMA will pump data from the camera ISP >to memory > - in the trickier YUV422 case, 3 DMAs will pump data from the camera >ISP pipes, one for pipe Y, one for pipe U and one for pipe V > > For these cases, it is necessary to split the original scatter list into > multiple scatter lists, which is the purpose of this patch. > > The guarantees that are required for this patch are : > - the intersection of spans of any couple of resulting scatter lists is >empty. > - the union of spans of all resulting scatter lists is a subrange of >the span of the original scatter list. > - streaming DMA API operations (mapping, unmapping) should not happen >both on both the resulting and the original scatter list. It's either >the first or the later ones. > - the caller is reponsible to call kfree() on the resulting >scatterlists. > > Signed-off-by: Robert Jarzmik > > --- > Since RFC: Russell's review > - address both the sg_phys case and sg_dma_address case (aka mapped >case) >=> this should take care of IOMMU coalescing > - add a way to return the new mapped lengths of resulting scatterlists > - add bound checks (EINVAL) for corner cases : > - skip > sum(sgi->length) or >skip > sum(sg_dma_len(sgi)) > - sum(sizei) > skip + sum(sgi->length) or >sum(sizei) > skip + sum(sg_dma_len(sgi)) > - fixed algorithm for single sgi split into multiple sg entries >(case where very small sizes, ie. size0+size1+size2 < sg0_length) > > Testing: > A semi-automated campaign was passed on this, and fixed last sg marking, > unused sg dma_len/dma_address, and cases where a sum of sizes landed at > the end of an sg entry. Valgrind was also passed to prevent memory > errors. > The input combinations of the tests were : > - skip: random > - sg : random of 1 to 10 entries, random phys address/values, 1/4th > random to have 2 sgs consecutive and coallesced in dma_map_sg() > - sizes[7] : random, sum(sizes) < 2 * sum(sgi->length) > > Memo of people to ask: > To: Russell King - ARM Linux > To: Jens Axboe > To: Guennadi Liakhovetski > To: Andrew Morton > To: Mauro Carvalho Chehab > Cc: linux-me...@vger.kernel.org > --- > include/linux/scatterlist.h | 5 ++ > lib/Kconfig | 7 ++ > lib/Makefile| 1 + > lib/sg_split.c | 202 > > 4 files changed, 215 insertions(+) > create mode 100644 lib/sg_split.c > > diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h > index 9b1ef0c820a7..5fa4ab1a4605 100644 > --- a/include/linux/scatterlist.h > +++ b/include/linux/scatterlist.h > @@ -251,6 +251,11 @@ struct scatterlist *sg_next(struct scatterlist *); > struct scatterlist *sg_last(struct scatterlist *s, unsigned int); > void sg_init_table(struct scatterlist *, unsigned int); > void sg_init_one(struct scatterlist *, const void *, unsigned int); > +int sg_split(struct scatterlist *in, const int in_mapped_nents, > + const off_t skip, const int nb_splits, > + const size_t *split_sizes, > + struct scatterlist **out, int *out_mapped_nents, > + gfp_t gfp_mask); > > typedef struct scatterlist *(sg_alloc_fn)(unsigned int, gfp_t); > typedef void (sg_free_fn)(struct scatterlist *, unsigned int); > diff --git a/lib/Kconfig b/lib/Kconfig > index 3a2ef67db6c7..dc516164415a 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -521,6 +521,13 @@ config UCS2_STRING > > source "lib/fonts/Kconfig" > > +config SG_SPLIT > + def_bool n > + help > + Provides a heler to split scatterlists into chunks, each chunk being a > + scatterlist. This should be selected by a driver or an API which > + whishes to split a scatterlist amongst multiple DMA channel. > + > # > # sg chaining option > # > diff --git a/lib/Makefile b/lib/Makefile > index 6897b527581a..2ee6ea2e9b08 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -160,6 +160,7 @@ obj-$(CONFIG_GENERIC_STRNLEN_USER) += strnlen_user.o > > obj-$(CONFIG_GENERIC_NET_UTILS) += net_utils.o > > +obj-$(CONFIG_SG_SPLIT) += sg_split.o > obj-$(CONFIG_STMP_DEVICE) += stmp_device.o > > libfdt_files = fdt.o fdt_ro.o fdt_wip.o
Re: [PATCH 13/18] iio: adc: mcp320x: Set struct spi_driver .of_match_table
On 21/08/15 00:53, Michael Welling wrote: > On Fri, Aug 21, 2015 at 12:48:23AM +0200, Javier Martinez Canillas wrote: >> Hello Michael, >> >> On 08/21/2015 12:29 AM, Michael Welling wrote: >>> On Fri, Aug 21, 2015 at 12:02:40AM +0200, Javier Martinez Canillas wrote: Hello Michael, On 08/20/2015 10:09 PM, Michael Welling wrote: > On Thu, Aug 20, 2015 at 09:07:26AM +0200, Javier Martinez Canillas wrote: >> The driver has an OF id table but the .of_match_table is not set so >> the SPI core can't do an OF style match and the table was unused. >> > > Is an OF style match necessary? > Did you read the cover letter [0] on which I explain why is needed to avoid breaking module autoloading in the future? Once the SPI core is changed by RFC patch 18/18? (you were cc'ed in the cover letter BTW). >>> >>> Well I have read it now. :) >>> >> >> Great :) >> > I have been using devicetree and it matches based on the .id_table. > Yes it fallbacks to the .id_table or the driver name but the correct thing to do for devices registered by OF, is to match using the compatible string. > Couldn't we just remove the mcp320x_dt_ids table instead? > No, that is the wrong thing to do IMHO since the compatible string contains both vendor and device name whle the .id_table only contains a device name. So it makes sense to match using the compatible string and also report the OF modalias information to user-space. Otherwise what's the point of the vendor in the compatible string for SPI devices? You can just use "bar" instead of "foo,bar" as a string. >>> >>> Well then shouldn't the patch include adding the vendor to the compatible >>> string? >>> >> >> Well, I was talking in general. You are right that this specific driver does >> not have a vendor prefix for the compatible strings. This is incorrect >> according to the ePAPR document [0]. >> >> However, these compatible strings are already documented as a DT binding doc >> in Documentation/devicetree/bindings/iio/adc/mcp320x.txt so I don't know >> what is the correct thing to do in this situation. >> >> Changing the compatible string will break old DTB with newer kernels and that >> is a no go. But that doesn't invalidate what I said since once the SPI core >> is changed and report OF modalias, you will need a >> MODULE_DEVICE_TABLE(of,...) >> regardless if the compatible string has a vendor prefix or not. >> > > Okay. > > Acked-by: Michael Welling Applied to the togreg branch of iio.git Thanks, Jonathan > >> [0]: https://www.power.org/documentation/epapr-version-1-1/ >> >> Best regards, >> -- >> Javier Martinez Canillas >> Open Source Group >> Samsung Research America > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/18] iio: Export SPI module alias information in missing drivers
On 20/08/15 16:49, Lars-Peter Clausen wrote: > On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote: >> The SPI core always reports the MODALIAS uevent as "spi:" >> regardless of the mechanism that was used to register the device >> (i.e: OF or board code) and the table that is used later to match >> the driver with the device (i.e: SPI id table or OF match table). >> >> So drivers needs to export the SPI id table and this be built into >> the module or udev won't have the necessary information to autoload >> the needed driver module when the device is added. >> >> Signed-off-by: Javier Martinez Canillas > > Acked-by: Lars-Peter Clausen Applied to the togreg branch of iio.git - initially pushed out as testing. Thanks, Jonathan > > Thanks. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/18] iio: dac: ad7303: Add OF match table
On 20/08/15 16:49, Lars-Peter Clausen wrote: > On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote: >> The Documentation/devicetree/bindings/iio/dac/ad7303.txt DT binding doc >> lists "adi,ad7303" as a compatible string but the corresponding driver >> does not have an OF match table. Add the table to the driver so the SPI >> core can do an OF style match. >> >> Signed-off-by: Javier Martinez Canillas > > > Acked-by: Lars-Peter Clausen Applied to the togreg branch of iio.git - pushed out as testing. Thanks, Jonathan > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/18] iio: frequency: adf4350: Add OF match table
On 20/08/15 16:49, Lars-Peter Clausen wrote: > On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote: >> The Documentation/devicetree/bindings/iio/frequency/adf4350.txt DT binding >> doc lists "adi,adf4350" or "adi,adf4351" as compatible strings but the >> corresponding driver does not have an OF match table. Add the table to the >> driver so the SPI core can do an OF style match. >> >> Signed-off-by: Javier Martinez Canillas > > Acked-by: Lars-Peter Clausen Applied to the togreg branch of iio.git Thanks, > > Thanks. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/18] iio: adc128s052: Add OF match table
On 20/08/15 08:07, Javier Martinez Canillas wrote:
> The Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt DT binding
> doc lists "ti,adc128s052" or "ti,adc122s021" as compatible strings but the
> corresponding driver does not have an OF match table. Add the table to the
> driver so the SPI core can do an OF style match.
>
> Signed-off-by: Javier Martinez Canillas
Applied to the togreg branch of iio.git - pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> drivers/iio/adc/ti-adc128s052.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/ti-adc128s052.c b/drivers/iio/adc/ti-adc128s052.c
> index 915be6b60097..98c0d2b444bf 100644
> --- a/drivers/iio/adc/ti-adc128s052.c
> +++ b/drivers/iio/adc/ti-adc128s052.c
> @@ -174,6 +174,13 @@ static int adc128_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id adc128_of_match[] = {
> + { .compatible = "ti,adc128s052", },
> + { .compatible = "ti,adc122s021", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, adc128_of_match);
> +
> static const struct spi_device_id adc128_id[] = {
> { "adc128s052", 0}, /* index into adc128_config */
> { "adc122s021", 1},
> @@ -184,6 +191,7 @@ MODULE_DEVICE_TABLE(spi, adc128_id);
> static struct spi_driver adc128_driver = {
> .driver = {
> .name = "adc128s052",
> + .of_match_table = of_match_ptr(adc128_of_match),
> .owner = THIS_MODULE,
> },
> .probe = adc128_probe,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/18] iio: as3935: Add OF match table
On 20/08/15 08:07, Javier Martinez Canillas wrote:
> The Documentation/devicetree/bindings/iio/proximity/as3935.txt DT binding
> doc lists "ams,as3935" as a compatible string but the corresponding driver
> does not have an OF match table. Add the table to the driver so the SPI
> core can do an OF style match.
>
> Signed-off-by: Javier Martinez Canillas
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.
> ---
>
> drivers/iio/proximity/as3935.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
> index bc0d68efd455..e95035136889 100644
> --- a/drivers/iio/proximity/as3935.c
> +++ b/drivers/iio/proximity/as3935.c
> @@ -434,6 +434,12 @@ static int as3935_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id as3935_of_match[] = {
> + { .compatible = "ams,as3935", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, as3935_of_match);
> +
> static const struct spi_device_id as3935_id[] = {
> {"as3935", 0},
> {},
> @@ -443,6 +449,7 @@ MODULE_DEVICE_TABLE(spi, as3935_id);
> static struct spi_driver as3935_driver = {
> .driver = {
> .name = "as3935",
> + .of_match_table = of_match_ptr(as3935_of_match),
> .owner = THIS_MODULE,
> .pm = AS3935_PM_OPS,
> },
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/18] iio: adc: max1027: Set struct spi_driver .of_match_table
On 20/08/15 08:07, Javier Martinez Canillas wrote:
> The driver has an OF id table but the .of_match_table is not set so
> the SPI core can't do an OF style match and the table was unused.
>
> Signed-off-by: Javier Martinez Canillas
Applied to the togreg branch of iio.git
Thanks,
Joanthan
> ---
>
> drivers/iio/adc/max1027.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/adc/max1027.c b/drivers/iio/adc/max1027.c
> index 44bf815adb6c..54a8302aaace 100644
> --- a/drivers/iio/adc/max1027.c
> +++ b/drivers/iio/adc/max1027.c
> @@ -508,6 +508,7 @@ static int max1027_remove(struct spi_device *spi)
> static struct spi_driver max1027_driver = {
> .driver = {
> .name = "max1027",
> + .of_match_table = of_match_ptr(max1027_adc_dt_ids),
> .owner = THIS_MODULE,
> },
> .probe = max1027_probe,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/18] staging: iio: hmc5843: Export missing SPI module alias information
On 20/08/15 08:07, Javier Martinez Canillas wrote:
> The SPI core always reports the MODALIAS uevent as "spi:"
> regardless of the mechanism that was used to register the device
> (i.e: OF or board code) and the table that is used later to match
> the driver with the device (i.e: SPI id table or OF match table).
>
> So drivers needs to export the SPI id table and this be built into
> the module or udev won't have the necessary information to autoload
> the needed driver module when the device is added.
>
> Signed-off-by: Javier Martinez Canillas
Applied to the togreg branch of iio.git.
This is too late for the upcoming merge window so it will be queued up for
the next one.
Thanks,
Jonathan
> ---
>
> drivers/staging/iio/magnetometer/hmc5843_spi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/iio/magnetometer/hmc5843_spi.c
> b/drivers/staging/iio/magnetometer/hmc5843_spi.c
> index 8e658f736e1f..4dfb372d2fec 100644
> --- a/drivers/staging/iio/magnetometer/hmc5843_spi.c
> +++ b/drivers/staging/iio/magnetometer/hmc5843_spi.c
> @@ -81,6 +81,7 @@ static const struct spi_device_id hmc5843_id[] = {
> { "hmc5983", HMC5983_ID },
> { }
> };
> +MODULE_DEVICE_TABLE(spi, hmc5843_id);
>
> static struct spi_driver hmc5843_driver = {
> .driver = {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: add 'crashkernel=auto' entry into kernel-parameters.txt
On 08/21/15 23:51, Yaowei Bai wrote: > There is no 'crashkernel=auto' entry in kernel-parameters.txt, borrow it > from kexec-kdump-howto.txt file in the kexec-tools-2.0.0 package. > > Signed-off-by: Yaowei Bai > --- > Documentation/kernel-parameters.txt | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/kernel-parameters.txt > b/Documentation/kernel-parameters.txt > index 1d6f045..4da77fa 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -797,6 +797,15 @@ bytes respectively. Such letter suffixes can also be > entirely omitted. > It will be ignored when crashkernel=X,high is not used > or memory reserved is below 4G. > > + crashkernel=auto > + This specification allows the kernel to decide how much > + meory to reserve for the purposes of kdump. It will make memory > + this determination based on the amount of memory you > have > + in your system, and scale the allocation accordingly. > + Note that if you have less than 4Gb of memory in your > system, > + this specification will opt to not allocate any memory > for > + the purposes of kdump. > + > cs89x0_dma= [HW,NET] > Format: > > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 13/18] iio: adc: mcp320x: Set struct spi_driver .of_match_table
On 20/08/15 23:48, Javier Martinez Canillas wrote: > Hello Michael, > > On 08/21/2015 12:29 AM, Michael Welling wrote: >> On Fri, Aug 21, 2015 at 12:02:40AM +0200, Javier Martinez Canillas wrote: >>> Hello Michael, >>> >>> On 08/20/2015 10:09 PM, Michael Welling wrote: On Thu, Aug 20, 2015 at 09:07:26AM +0200, Javier Martinez Canillas wrote: > The driver has an OF id table but the .of_match_table is not set so > the SPI core can't do an OF style match and the table was unused. > Is an OF style match necessary? >>> >>> Did you read the cover letter [0] on which I explain why is needed to >>> avoid breaking module autoloading in the future? Once the SPI core is >>> changed by RFC patch 18/18? (you were cc'ed in the cover letter BTW). >> >> Well I have read it now. :) >> > > Great :) > >>> I have been using devicetree and it matches based on the .id_table. >>> >>> Yes it fallbacks to the .id_table or the driver name but the correct >>> thing to do for devices registered by OF, is to match using the >>> compatible string. >>> Couldn't we just remove the mcp320x_dt_ids table instead? >>> >>> No, that is the wrong thing to do IMHO since the compatible string >>> contains both vendor and device name whle the .id_table only contains >>> a device name. >>> >>> So it makes sense to match using the compatible string and also report >>> the OF modalias information to user-space. >>> >>> Otherwise what's the point of the vendor in the compatible string for >>> SPI devices? You can just use "bar" instead of "foo,bar" as a string. >>> >> >> Well then shouldn't the patch include adding the vendor to the compatible >> string? >> > > Well, I was talking in general. You are right that this specific driver does > not have a vendor prefix for the compatible strings. This is incorrect > according to the ePAPR document [0]. > > However, these compatible strings are already documented as a DT binding doc > in Documentation/devicetree/bindings/iio/adc/mcp320x.txt so I don't know > what is the correct thing to do in this situation. Take the view the old version is wrong but needs to be supported and add also the corrected strings + document them. cc'd The device tree list for any more comments on this. > > Changing the compatible string will break old DTB with newer kernels and that > is a no go. But that doesn't invalidate what I said since once the SPI core > is changed and report OF modalias, you will need a MODULE_DEVICE_TABLE(of,...) > regardless if the compatible string has a vendor prefix or not. > > [0]: https://www.power.org/documentation/epapr-version-1-1/ > > Best regards, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
On 22/08/15 05:02, Wolfram Sang wrote: > The series[1] I am working on implements a i2c smbus block data regmap bus driver. Regmap should then automatically do a block read in regmap_bulk_read. >>> >>> Hmm, so doesn't your series make Irina's series obsolete? It >>> addresses >>> the same problem only at a different layer (i2c core vs. regmap), or? >>> It >>> would mean that i2c client drivers which want to support byte, word, >>> or >>> block transfers should be converted to regmap. I assume most of the >>> potential candidates are register based devices anyhow. Then, regmap >>> would be the proper abstraction layer. Have I overlooked something? >>> >> This is the only driver converted to use regmap, because of SPI mode >> support. The other drivers will still use Irina's changes. > > The question is if they should. Or rather be converted to regmap. It is > an open question and I am seeking for further input. > There are a fairly large number of legacy drivers where this might apply. Do we have any real idea of how many? I'm assuming Irina only made use of it in ones that were of personal interest. A quick grep suggests 10's of drivers use the block call. I'm guessing quite a few would use it if needed for a particular board. Do we want to insist on a much larger change (conversion to regmap) when if this in place, a simple single functional call change will do the job? Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] coccinelle: add style check for assignment in if
Add a semantic patch for fixing some cases of checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer
Acked-by: Julia Lawall
---
scripts/coccinelle/style/assignment_in_if.cocci | 128
1 file changed, 128 insertions(+)
create mode 100644 scripts/coccinelle/style/assignment_in_if.cocci
diff --git a/scripts/coccinelle/style/assignment_in_if.cocci
b/scripts/coccinelle/style/assignment_in_if.cocci
new file mode 100644
index 000..b23db8f
--- /dev/null
+++ b/scripts/coccinelle/style/assignment_in_if.cocci
@@ -0,0 +1,128 @@
+/// move assignments out of if conditions
+///
+//# This script is designed to correct code where assignments exist in if
+//# conditions. It is only capable of handling a subset of such problems.
+//# Ideally it would handle all checkpatch errors of the following type:
+//#ERROR: do not use assignment in if condition
+//#
+//# For example:
+//#if(result = myfun())
+//#
+//# would become:
+//#result = myfun();
+//#if(result)
+//
+// Confidence: Moderate
+// Copyright: (C) 2015 Kris Borer. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Comments:
+// Options: --no-includes --include-headers
+
+virtual patch
+
+
+// if ( (ret = call()) )
+// if ( (ret = call()) < 0 )
+@if1@
+expression i;
+expression E, E2;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+ if (
+(
+- (i = E)
++ i
+|
+- (i = E)
++ i
+ b ...
+|
+- (i = E),
+ E2
+)
+ ) S1 else S2
+
+
+// if ( ptr->fun && (ret = ptr->fun()) )
+@if2@
+expression i2;
+expression E1, E2;
+@@
+
++ if( E1 ) {
++ i2 = E2;
++ if (i2) {
+- if( E1 && (i2 = E2) ) {
+ ...
+- }
++ }
++ }
+
+
+// if ( ptr->fun && (ret = ptr->fun()) < 0 )
+@if3@
+expression i2;
+expression E1, E2;
+constant c;
+binary operator b;
+@@
+
++ if( E1 ) {
++ i2 = E2;
++ if (i2 b c) {
+- if( E1 && ((i2 = E2) b c) ) {
+ ...
+- }
++ }
++ }
+
+
+// if ( (ret = call()) && ret != -1 )
+// if ( (ret = call()) < 0 && ret != -1 )
+@if4@
+expression i;
+expression E, E2;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+ if (
+(
+- (i = E)
++ i
+|
+ (
+- (i = E)
++ i
+ b
+ ...)
+)
+ && E2 ) S1 else S2
+
+
+// if ( (ret = call()) && ret != -1 && ret != -2 )
+// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
+@if5@
+expression i;
+expression E, E2, E3;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+ if (
+(
+- (i = E)
++ i
+|
+ (
+- (i = E)
++ i
+ b
+ ...)
+)
+ && E2 && E3 ) S1 else S2
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem
On Fri, Aug 21, 2015 at 07:42:30PM +0200, Oleg Nesterov wrote: > Hello, > > Now that sb->s_writers was changed to use percpu_rw_semaphore let me > send v2. > > Changes: > > - whitespace fix in 1/8. > > - remove EXPORT_SYMBOL() in 3/8, currently rcu_sync has no > modular users. > > - 5/8 is new. This ugly hack pairs with another one: > "shift percpu_counter_destroy() into destroy_super_work()" > > https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/commit/?h=for-next=853b39a7c82826b8413048feec7bf08e98ce7a84 > They both will be reverted later. > > The problem is that we have 2 series routed via different > trees, RCU and VFS. We need this hack to ensure that this > series won't break alloc_super() which currently assumes that > destroy_super()->percpu_free_rwsem() is safe after kzalloc(). > This way these 2 series do not depend on each other, we can > test/change/revert/etc them independently. > > We will add rcu_sync_dtor() into deactivate_locked_super() > later and revert both hacks. > Oleg. Queued for testing, thank you, Oleg! Right now, this is mostly relying on 0day and -next testing. Any thoughts for a useful torture test for this? One approach would be to treat it like a reader-writer lock. Other thoughts? Thanx, Paul > include/linux/percpu-rwsem.h |3 +- > include/linux/rcusync.h | 56 +++ > kernel/locking/percpu-rwsem.c | 85 --- > kernel/rcu/Makefile |2 +- > kernel/rcu/sync.c | 151 > + > 5 files changed, 240 insertions(+), 57 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ata: pata_arasam_cf: Use devm_clk_get
On Sat, Aug 22, 2015 at 09:04:50AM +0530, Vaishali Thakkar wrote: > This patch introduces the use of managed resource function > devm_clk_get instead of clk_get and removes corresponding call > to clk_put in the remove function. > > To be compatible with the change various gotos are replaced with > direct returns, and unneeded label is dropped. > > Signed-off-by: Vaishali Thakkar Applied to libata/for-4.3. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3] coccinelle: add style check for assignment in if
Acked-by: Julia Lawall
However, I think it would be better to remove the "BAD" rulle at the end.
julia
On Thu, 20 Aug 2015, Kris Borer wrote:
> Add a semantic patch for fixing some cases of checkpatch.pl error:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by: Kris Borer
> ---
> Differences from Julia's version:
> - removed some disjuction variations that led to improper transformations
> - fixed header format
> - added and updated comments
> - reformatted some rules
>
> scripts/coccinelle/style/assignment_in_if.cocci | 140
>
> 1 file changed, 140 insertions(+)
> create mode 100644 scripts/coccinelle/style/assignment_in_if.cocci
>
> diff --git a/scripts/coccinelle/style/assignment_in_if.cocci
> b/scripts/coccinelle/style/assignment_in_if.cocci
> new file mode 100644
> index 000..57f692d
> --- /dev/null
> +++ b/scripts/coccinelle/style/assignment_in_if.cocci
> @@ -0,0 +1,140 @@
> +/// move assignments out of if conditions
> +///
> +//# This script is designed to correct code where assignments exist in if
> +//# conditions. It is only capable of handling a subset of such problems.
> +//# Ideally it would handle all checkpatch errors of the following type:
> +//# ERROR: do not use assignment in if condition
> +//#
> +//# For example:
> +//# if(result = myfun())
> +//#
> +//# would become:
> +//# result = myfun();
> +//# if(result)
> +//
> +// Confidence: Moderate
> +// Copyright: (C) 2015 Kris Borer. GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Comments:
> +// Options: --no-includes --include-headers
> +
> +virtual patch
> +
> +
> +// if ( (ret = call()) )
> +// if ( (ret = call()) < 0 )
> +@if1@
> +expression i;
> +expression E, E2;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> + if (
> +(
> +- (i = E)
> ++ i
> +|
> +- (i = E)
> ++ i
> + b ...
> +|
> +- (i = E),
> + E2
> +)
> + ) S1 else S2
> +
> +
> +// if ( ptr->fun && (ret = ptr->fun()) )
> +@if2@
> +expression i2;
> +expression E1, E2;
> +@@
> +
> ++ if( E1 ) {
> ++ i2 = E2;
> ++ if (i2) {
> +- if( E1 && (i2 = E2) ) {
> + ...
> +- }
> ++ }
> ++ }
> +
> +
> +// if ( ptr->fun && (ret = ptr->fun()) < 0 )
> +@if3@
> +expression i2;
> +expression E1, E2;
> +constant c;
> +binary operator b;
> +@@
> +
> ++ if( E1 ) {
> ++ i2 = E2;
> ++ if (i2 b c) {
> +- if( E1 && ((i2 = E2) b c) ) {
> + ...
> +- }
> ++ }
> ++ }
> +
> +
> +// if ( (ret = call()) && ret != -1 )
> +// if ( (ret = call()) < 0 && ret != -1 )
> +@if4@
> +expression i;
> +expression E, E2;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> + if (
> +(
> +- (i = E)
> ++ i
> +|
> + (
> +- (i = E)
> ++ i
> + b
> + ...)
> +)
> + && E2 ) S1 else S2
> +
> +
> +// if ( (ret = call()) && ret != -1 && ret != -2 )
> +// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
> +@if5@
> +expression i;
> +expression E, E2, E3;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> + if (
> +(
> +- (i = E)
> ++ i
> +|
> + (
> +- (i = E)
> ++ i
> + b
> + ...)
> +)
> + && E2 && E3 ) S1 else S2
> +
> +
> +// warn about any assignments that were missed
> +@if6@
> +expression i,e;
> +statement S1,S2;
> +@@
> +
> + if (<+...
> +- i = e
> ++ BAD
> + ...+>) S1 else S2
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [v3] x86, suspend: Save/restore THERM_CONTROL register for suspend
On 2015.08.22 04:03 Chen Yu wrote: > A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208) > that, after resuming from S3, CPU is working at a low speed. That bug report has restricted access, even if one creates a Red Hat Bugzilla account. Once I created an account I got: "Most likely the bug has been restricted for internal development processes and we cannot grant access." Can it be set for public access? As a side note on this one: The current version of the intel_pstate driver is incompatible with any use of Clock Modulation, always resulting in driving the target pstate to the minimum, regardless of load. The result is the apparent CPU frequency stuck at minimum * modulation percent. Proposed intel_pstate driver versions using some sort of C0 time again works fine with Clock Modulation, resulting in desired frequency * modulation percent. The acpi-cpufreq driver works fine with Clock Modulation, resulting in desired frequency * modulation percent. > After investigation, it is found that, BIOS has modified the value > of THERM_CONTROL register during S3, There are other reports of what I think is the same issue on other bug reports and forum posts. To confirm or deny, I am attempting to get sufferers to do your test and report back. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Do you need a loan?
We offer private, commercial and personal loans with very low annualinterest rates as low as 2% in one year to 50 years repayment period anywhere in the world. We offer loans ranging from $5000 to $100 million. Our loans are well insured for maximum security is our priority. Are you losing sleep at night worrying how to get a legitimate loan lender? You bite your nails that fast? Instead of beating you, contact JM Financial Services Ltd now, specialists who help stop loans bad credit history to find a solution that victory is our mission. Applicants must fill out a loan application form below: FORM credit application loan applications Your full name * Your e-mail * Your phone * Your address * Your city * State / Province * Country * Fax* Date of birth * Do you have an account? * Have you applied before? * The loan amount is needed * The life expectancy * The purpose of the loan * Send me a scanned copy of your passport: * Creditor: Mr. Prakash Lass Dickson. Company: JM Financial Services Ltd. Copyright JM Financial Ltd. All rights reserved. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xen/tmem: Pass page instead of pfn to xen_tmem_get_page()
On Thu, Aug 20, 2015 at 8:27 AM, David Vrabel wrote: > On 19/08/15 14:25, Murilo Opsfelder Araujo wrote: >> The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use >> xen_page_to_gfn rather than pfn_to_gfn" left behind a call to >> xen_tmem_get_page() receiving pfn instead of page. >> >> This change also fixes the following build warning: >> >> drivers/xen/tmem.c: In function ‘tmem_cleancache_get_page’: >> drivers/xen/tmem.c:194:47: warning: passing argument 4 of >> ‘xen_tmem_get_page’ makes pointer from integer without a cast >> ret = xen_tmem_get_page((u32)pool, oid, ind, pfn); >>^ >> drivers/xen/tmem.c:138:12: note: expected ‘struct page *’ but argument is of >> type ‘long unsigned int’ >> static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid, > > I've folded this in, thanks. > > David Thanks, David. -- Murilo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xen/tmem: Pass page instead of pfn to xen_tmem_get_page()
On Wed, Aug 19, 2015 at 9:23 PM, Julien Grall wrote: > Hi, > > On 19/08/2015 06:25, Murilo Opsfelder Araujo wrote: >> >> The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use >> xen_page_to_gfn rather than pfn_to_gfn" left behind a call to >> xen_tmem_get_page() receiving pfn instead of page. >> >> This change also fixes the following build warning: >> >> drivers/xen/tmem.c: In function ‘tmem_cleancache_get_page’: >> drivers/xen/tmem.c:194:47: warning: passing argument 4 of >> ‘xen_tmem_get_page’ makes pointer from integer without a cast >>ret = xen_tmem_get_page((u32)pool, oid, ind, pfn); >> ^ >> drivers/xen/tmem.c:138:12: note: expected ‘struct page *’ but argument is >> of type ‘long unsigned int’ >> static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid, >> ^ >> >> Signed-off-by: Murilo Opsfelder Araujo > > > Sorry for the breakage, I haven't spot it because CONFIG_CLEANCACHE is not > enabled on my config. > > Reviewed-by: Julien Grall > > Regards, > > -- > Julien Grall Hi, Julien. No need to apologize, and thanks for reviewing that. -- Murilo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm/vmalloc: Cache the /proc/meminfo vmalloc statistics
On Sat, Aug 22, 2015 at 3:44 AM, Ingo Molnar wrote: > > Would something like this be acceptable (and is it correct)? I don't think any of this can be called "correct", in that the unlocked accesses to the cached state are clearly racy, but I think it's very much "acceptable". 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: Regarding USER_HZ and the exposure of kernel jiffies in userspace
On Sat, 22 Aug 2015, William Breathitt Gray wrote: > I believe the error in my understanding is the assumption that _all_ > instances of kernel jiffies exposure in userspace should be scaled; but > it appears that not all instances are. When are kernel jiffies meant to > be scaled via USER_HZ, and when are they not? All instances which are de facto APIs, syscalls and also various files in proc/ must be in USER_HZ because userspace applications depend on the USER_HZ value. proc/timer_list is exempt from that because its more a debugging interface which is not part of the strict kernel API. And we really want to see the real values and not the scaled USER_HZ ones for that purpose. I hope that answers your question. 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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
22.08.2015 15:38, Ingo Molnar пишет: [...] We could add yet more heuristics and teach sigreturn to ignore the saved SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable. We could maybe try this - assuming it doesn't break DOSEMU. Or we could extend the ABI and allow DOSEMU to cleanly use it. I'm not sure it's worth the complexity, given that the DOSEMU workaround already exists and will likely exist forever, so that it can support older kernels, right? That assumes dosemu is the only current and future user of that functionality. That's why I raised the question whether does Wine want to support a 32/16bit code in its 64bit builds too. So far it doesn't have such functionality, likely waiting for the kernel to provide it, rather than going the route of hacks and work-arounds as dosemu did. Also, the fact that dosemu already have that functionality, doesn't mean it will not use the new API - it actually will. With a few run-time checks at first, but when all distros are upgraded, there is simply no point to support the kernels that are not in any current distro (after a few years of deprecation perhaps). Overall, I think the existance of a few hacks in dosemu is not the reason for the linux kernel to stop any development in that area. dosemu did a great work of exploring all the pitfalls in that area, so now you know what to fix and how. Please, keep the things going. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] staging: lustre: fix GLOBAL_INITIALISERS checkpatch.pl errors
Fix occurencies of the following checkpatch.pl error:
ERROR: do not initialise globals to 0 or NULL
Signed-off-by: Mike Rapoport
---
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c| 4 ++--
drivers/staging/lustre/lustre/libcfs/fail.c | 4 ++--
drivers/staging/lustre/lustre/obdclass/capa.c | 2 +-
drivers/staging/lustre/lustre/obdclass/class_obd.c| 8
drivers/staging/lustre/lustre/obdclass/lprocfs_counters.c | 2 +-
drivers/staging/lustre/lustre/obdclass/lu_object.c| 4 ++--
drivers/staging/lustre/lustre/obdclass/obd_config.c | 4 ++--
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
index 4bb3173..cc212b9 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
@@ -47,8 +47,8 @@
struct kmem_cache *ldlm_resource_slab, *ldlm_lock_slab;
-int ldlm_srv_namespace_nr = 0;
-int ldlm_cli_namespace_nr = 0;
+int ldlm_srv_namespace_nr;
+int ldlm_cli_namespace_nr;
struct mutex ldlm_srv_namespace_lock;
LIST_HEAD(ldlm_srv_namespace_list);
diff --git a/drivers/staging/lustre/lustre/libcfs/fail.c
b/drivers/staging/lustre/lustre/libcfs/fail.c
index 42d615f..d39fece 100644
--- a/drivers/staging/lustre/lustre/libcfs/fail.c
+++ b/drivers/staging/lustre/lustre/libcfs/fail.c
@@ -35,10 +35,10 @@
#include "../../include/linux/libcfs/libcfs.h"
-unsigned long cfs_fail_loc = 0;
+unsigned long cfs_fail_loc;
EXPORT_SYMBOL(cfs_fail_loc);
-unsigned int cfs_fail_val = 0;
+unsigned int cfs_fail_val;
EXPORT_SYMBOL(cfs_fail_val);
DECLARE_WAIT_QUEUE_HEAD(cfs_race_waitq);
diff --git a/drivers/staging/lustre/lustre/obdclass/capa.c
b/drivers/staging/lustre/lustre/obdclass/capa.c
index d8d1a66..99af017 100644
--- a/drivers/staging/lustre/lustre/obdclass/capa.c
+++ b/drivers/staging/lustre/lustre/obdclass/capa.c
@@ -58,7 +58,7 @@
#define NR_CAPAHASH 32
#define CAPA_HASH_SIZE 3000 /* for MDS & OSS */
-struct kmem_cache *capa_cachep = NULL;
+struct kmem_cache *capa_cachep;
/* lock for capa hash/capa_list/fo_capa_keys */
DEFINE_SPINLOCK(capa_lock);
diff --git a/drivers/staging/lustre/lustre/obdclass/class_obd.c
b/drivers/staging/lustre/lustre/obdclass/class_obd.c
index 130c4e3..b151154 100644
--- a/drivers/staging/lustre/lustre/obdclass/class_obd.c
+++ b/drivers/staging/lustre/lustre/obdclass/class_obd.c
@@ -53,9 +53,9 @@ EXPORT_SYMBOL(obd_devs);
struct list_head obd_types;
DEFINE_RWLOCK(obd_dev_lock);
-__u64 obd_max_pages = 0;
+__u64 obd_max_pages;
EXPORT_SYMBOL(obd_max_pages);
-__u64 obd_max_alloc = 0;
+__u64 obd_max_alloc;
EXPORT_SYMBOL(obd_max_alloc);
__u64 obd_alloc;
EXPORT_SYMBOL(obd_alloc);
@@ -64,7 +64,7 @@ EXPORT_SYMBOL(obd_pages);
static DEFINE_SPINLOCK(obd_updatemax_lock);
/* The following are visible and mutable through /proc/sys/lustre/. */
-unsigned int obd_alloc_fail_rate = 0;
+unsigned int obd_alloc_fail_rate;
EXPORT_SYMBOL(obd_alloc_fail_rate);
unsigned int obd_debug_peer_on_timeout;
EXPORT_SYMBOL(obd_debug_peer_on_timeout);
@@ -81,7 +81,7 @@ EXPORT_SYMBOL(obd_timeout);
unsigned int obd_timeout_set;
EXPORT_SYMBOL(obd_timeout_set);
/* Adaptive timeout defs here instead of ptlrpc module for /proc/sys/ access */
-unsigned int at_min = 0;
+unsigned int at_min;
EXPORT_SYMBOL(at_min);
unsigned int at_max = 600;
EXPORT_SYMBOL(at_max);
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_counters.c
b/drivers/staging/lustre/lustre/obdclass/lprocfs_counters.c
index c49dfe5..1f0004c 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_counters.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_counters.c
@@ -41,7 +41,7 @@
#include "../include/lprocfs_status.h"
#include "../include/obd_support.h"
-struct lprocfs_stats *obd_memory = NULL;
+struct lprocfs_stats *obd_memory;
EXPORT_SYMBOL(obd_memory);
void lprocfs_counter_add(struct lprocfs_stats *stats, int idx, long amount)
diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c
b/drivers/staging/lustre/lustre/obdclass/lu_object.c
index 8e47232..55d4523 100644
--- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
@@ -1689,8 +1689,8 @@ EXPORT_SYMBOL(lu_context_refill);
* predefined when the lu_device type are registered, during the module probe
* phase.
*/
-__u32 lu_context_tags_default = 0;
-__u32 lu_session_tags_default = 0;
+__u32 lu_context_tags_default;
+__u32 lu_session_tags_default;
void lu_context_tags_update(__u32 tags)
{
diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c
b/drivers/staging/lustre/lustre/obdclass/obd_config.c
index 953e4c8..d399cae 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_config.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c
@@ -931,8 +931,8 @@ static int class_set_global(char *ptr, int val, struct
lustre_cfg
[PATCH 2/5] staging: lustre: fix CODE_INDENT checkpatch.pl errors
Fix occurencies of the following checkpatch.pl error:
ERROR: code indent should use tabs where possible
Signed-off-by: Mike Rapoport
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 2 +-
drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index 4f9c5c8..d0c79d1 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -626,7 +626,7 @@ ksocknal_find_conn_locked(ksock_peer_t *peer, ksock_tx_t
*tx, int nonblk)
list_for_each (tmp, >ksnp_conns) {
ksock_conn_t *c = list_entry(tmp, ksock_conn_t, ksnc_list);
int nob = atomic_read(>ksnc_tx_nob) +
- c->ksnc_sock->sk->sk_wmem_queued;
+ c->ksnc_sock->sk->sk_wmem_queued;
int rc;
LASSERT(!c->ksnc_closing);
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 3407061..679785b 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -355,9 +355,9 @@ ksocknal_lib_recv_kiov(ksock_conn_t *conn)
LASSERT(i < niov);
/* Dang! have to kmap again because I have nowhere to
- * stash the mapped address. But by doing it while the
- * page is still mapped, the kernel just bumps the map
- * count and returns me the address it stashed. */
+* stash the mapped address. But by doing it while the
+* page is still mapped, the kernel just bumps the map
+* count and returns me the address it stashed. */
base = kmap(kiov[i].kiov_page) + kiov[i].kiov_offset;
fragnob = kiov[i].kiov_len;
if (fragnob > sum)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] staging: lustre: fix OPEN_BRACE checkpatch.pl errors
Fix occurencies of the following checkpatch.pl error:
ERROR: open brace '{' following function declarations go on
the next line
Signed-off-by: Mike Rapoport
---
drivers/staging/lustre/lustre/include/lprocfs_status.h | 3 ++-
drivers/staging/lustre/lustre/include/lustre/lustre_user.h | 3 ++-
drivers/staging/lustre/lustre/obdclass/cl_object.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index fd3c4df..213666b 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -206,7 +206,8 @@ struct lprocfs_stats {
#define OPC_RANGE(seg) (seg ## _LAST_OPC - seg ## _FIRST_OPC)
/* Pack all opcodes down into a single monotonically increasing index */
-static inline int opcode_offset(__u32 opc) {
+static inline int opcode_offset(__u32 opc)
+{
if (opc < OST_LAST_OPC) {
/* OST opcode */
return (opc - OST_FIRST_OPC);
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index d2836a8..e9925ef 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -658,7 +658,8 @@ enum changelog_rec_type {
CL_LAST
};
-static inline const char *changelog_type2str(int type) {
+static inline const char *changelog_type2str(int type)
+{
static const char *changelog_str[] = {
"MARK", "CREAT", "MKDIR", "HLINK", "SLINK", "MKNOD", "UNLNK",
"RMDIR", "RENME", "RNMTO", "OPEN", "CLOSE", "LYOUT", "TRUNC",
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index fb9a854..cf390d6 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -653,7 +653,8 @@ static inline void cl_env_do_detach(struct cl_env *cle)
cle->ce_owner = NULL;
}
-static int cl_env_store_init(void) {
+static int cl_env_store_init(void)
+{
cl_env_hash = cfs_hash_create("cl_env",
HASH_CL_ENV_BITS, HASH_CL_ENV_BITS,
HASH_CL_ENV_BKT_BITS, 0,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] staging: lustre: fix SWITCH_CASE_INDENT_LEVEL checkpatch.pl errors
Fix occurencies of the following checkpatch.pl error:
ERROR: switch and case should be at the same indent
Signed-off-by: Mike Rapoport
---
drivers/staging/lustre/lnet/selftest/selftest.h| 20 ++--
.../lustre/lustre/libcfs/linux/linux-tracefile.c | 22 ++
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/selftest.h
b/drivers/staging/lustre/lnet/selftest/selftest.h
index dfe3342..160d68c 100644
--- a/drivers/staging/lustre/lnet/selftest/selftest.h
+++ b/drivers/staging/lustre/lnet/selftest/selftest.h
@@ -563,16 +563,16 @@ swi_state2str (int state)
{
#define STATE2STR(x) case x: return #x
switch (state) {
- default:
- LBUG();
- STATE2STR(SWI_STATE_NEWBORN);
- STATE2STR(SWI_STATE_REPLY_SUBMITTED);
- STATE2STR(SWI_STATE_REPLY_SENT);
- STATE2STR(SWI_STATE_REQUEST_SUBMITTED);
- STATE2STR(SWI_STATE_REQUEST_SENT);
- STATE2STR(SWI_STATE_REPLY_RECEIVED);
- STATE2STR(SWI_STATE_BULK_STARTED);
- STATE2STR(SWI_STATE_DONE);
+ default:
+ LBUG();
+ STATE2STR(SWI_STATE_NEWBORN);
+ STATE2STR(SWI_STATE_REPLY_SUBMITTED);
+ STATE2STR(SWI_STATE_REPLY_SENT);
+ STATE2STR(SWI_STATE_REQUEST_SUBMITTED);
+ STATE2STR(SWI_STATE_REQUEST_SENT);
+ STATE2STR(SWI_STATE_REPLY_RECEIVED);
+ STATE2STR(SWI_STATE_BULK_STARTED);
+ STATE2STR(SWI_STATE_DONE);
}
#undef STATE2STR
}
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
index eb10e3b..87d8449 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
@@ -212,12 +212,11 @@ static char *
dbghdr_to_err_string(struct ptldebug_header *hdr)
{
switch (hdr->ph_subsys) {
-
- case S_LND:
- case S_LNET:
- return "LNetError";
- default:
- return "LustreError";
+ case S_LND:
+ case S_LNET:
+ return "LNetError";
+ default:
+ return "LustreError";
}
}
@@ -225,12 +224,11 @@ static char *
dbghdr_to_info_string(struct ptldebug_header *hdr)
{
switch (hdr->ph_subsys) {
-
- case S_LND:
- case S_LNET:
- return "LNet";
- default:
- return "Lustre";
+ case S_LND:
+ case S_LNET:
+ return "LNet";
+ default:
+ return "Lustre";
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] staging: lustre: fix whitespace errors reported by checkpatch.pl
Added/removed spaces and replaced '+1' with '1' in several places to
eliminate SPACING and POINTER_LOCATION errors reported by checkpatch.pl
Signed-off-by: Mike Rapoport
---
.../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 4 +-
drivers/staging/lustre/lnet/selftest/conrpc.h | 4 +-
drivers/staging/lustre/lnet/selftest/console.c | 16 +--
drivers/staging/lustre/lnet/selftest/selftest.h| 2 +-
drivers/staging/lustre/lustre/include/cl_object.h | 14 +-
drivers/staging/lustre/lustre/include/lu_object.h | 16 +--
.../lustre/lustre/include/lustre/lustre_idl.h | 12 +-
.../lustre/lustre/include/lustre/lustre_user.h | 4 +-
.../staging/lustre/lustre/include/lustre_capa.h| 2 +-
.../staging/lustre/lustre/include/lustre_disk.h| 2 +-
drivers/staging/lustre/lustre/include/lustre_dlm.h | 6 +-
.../lustre/lustre/include/lustre_dlm_flags.h | 152 ++---
drivers/staging/lustre/lustre/include/lustre_lib.h | 6 +-
drivers/staging/lustre/lustre/include/lustre_net.h | 2 +-
drivers/staging/lustre/lustre/include/obd.h| 2 +-
.../staging/lustre/lustre/include/obd_support.h| 2 +-
drivers/staging/lustre/lustre/libcfs/tracefile.c | 4 +-
drivers/staging/lustre/lustre/llite/file.c | 4 +-
.../staging/lustre/lustre/llite/llite_internal.h | 2 +-
drivers/staging/lustre/lustre/llite/lproc_llite.c | 2 +-
drivers/staging/lustre/lustre/llite/rw.c | 6 +-
drivers/staging/lustre/lustre/llite/statahead.c| 4 +-
drivers/staging/lustre/lustre/llite/vvp_io.c | 2 +-
drivers/staging/lustre/lustre/lmv/lmv_obd.c| 2 +-
drivers/staging/lustre/lustre/lov/lov_obd.c| 4 +-
drivers/staging/lustre/lustre/obdclass/cl_io.c | 10 +-
drivers/staging/lustre/lustre/obdclass/cl_lock.c | 6 +-
drivers/staging/lustre/lustre/obdclass/cl_object.c | 2 +-
drivers/staging/lustre/lustre/obdclass/class_obd.c | 4 +-
drivers/staging/lustre/lustre/obdclass/genops.c| 6 +-
drivers/staging/lustre/lustre/obdclass/llog.c | 4 +-
.../staging/lustre/lustre/obdclass/obd_config.c| 2 +-
drivers/staging/lustre/lustre/osc/osc_request.c| 6 +-
.../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 2 +-
34 files changed, 159 insertions(+), 159 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index 0d5aac6..4f9c5c8 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -714,7 +714,7 @@ ksocknal_queue_tx_locked (ksock_tx_t *tx, ksock_conn_t
*conn)
LASSERT(tx->tx_resid == tx->tx_nob);
CDEBUG (D_NET, "Packet %p type %d, nob %d niov %d nkiov %d\n",
- tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type:
+ tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type :
KSOCK_MSG_NOOP,
tx->tx_nob, tx->tx_niov, tx->tx_nkiov);
@@ -1092,7 +1092,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_iov[niov].iov_len = nob;
niov++;
skipped += nob;
- nob_to_skip -=nob;
+ nob_to_skip -= nob;
} while (nob_to_skip != 0 &&/* mustn't overflow conn's rx iov */
niov < sizeof(conn->ksnc_rx_iov_space) / sizeof (struct
iovec));
diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.h
b/drivers/staging/lustre/lnet/selftest/conrpc.h
index 7d33cf9..ae7ed75 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.h
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.h
@@ -105,8 +105,8 @@ typedef struct lstcon_rpc_trans {
#define LST_TRANS_STATQRY 0x21
-typedef int (* lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
-typedef int (* lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t
*);
+typedef int (*lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
+typedef int (*lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t
*);
int lstcon_sesrpc_prep(struct lstcon_node *nd, int transop,
unsigned version, lstcon_rpc_t **crpc);
diff --git a/drivers/staging/lustre/lnet/selftest/console.c
b/drivers/staging/lustre/lnet/selftest/console.c
index f47c8f2..5c624e1 100644
--- a/drivers/staging/lustre/lnet/selftest/console.c
+++ b/drivers/staging/lustre/lnet/selftest/console.c
@@ -308,7 +308,7 @@ lstcon_group_ndlink_release(lstcon_group_t *grp,
lstcon_ndlink_t *ndl)
{
list_del_init(>ndl_link);
lstcon_ndlink_release(ndl);
- grp->grp_nnode --;
+ grp->grp_nnode--;
}
static void
@@ -320,7 +320,7 @@ lstcon_group_ndlink_move(lstcon_group_t *old,
list_del(>ndl_hlink);
list_del(>ndl_link);
- old->grp_nnode --;
+ old->grp_nnode--;
list_add_tail(>ndl_hlink,
[PATCH 0/5] staging: lustre: fix some trivial checpatck.pl errors
Hi, These patches fix some trivial checkpatch.pl errors, like spacing, identation etc. Mike Rapoport (5): staging: lustre: fix whitespace errors reported by checkpatch.pl staging: lustre: fix CODE_INDENT checkpatch.pl errors staging: lustre: fix GLOBAL_INITIALISERS checkpatch.pl errors staging: lustre: fix SWITCH_CASE_INDENT_LEVEL checkpatch.pl errors staging: lustre: fix OPEN_BRACE checkpatch.pl errors .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 6 +- .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 6 +- drivers/staging/lustre/lnet/selftest/conrpc.h | 4 +- drivers/staging/lustre/lnet/selftest/console.c | 16 +-- drivers/staging/lustre/lnet/selftest/selftest.h| 22 +-- drivers/staging/lustre/lustre/include/cl_object.h | 14 +- .../staging/lustre/lustre/include/lprocfs_status.h | 3 +- drivers/staging/lustre/lustre/include/lu_object.h | 16 +-- .../lustre/lustre/include/lustre/lustre_idl.h | 12 +- .../lustre/lustre/include/lustre/lustre_user.h | 7 +- .../staging/lustre/lustre/include/lustre_capa.h| 2 +- .../staging/lustre/lustre/include/lustre_disk.h| 2 +- drivers/staging/lustre/lustre/include/lustre_dlm.h | 6 +- .../lustre/lustre/include/lustre_dlm_flags.h | 152 ++--- drivers/staging/lustre/lustre/include/lustre_lib.h | 6 +- drivers/staging/lustre/lustre/include/lustre_net.h | 2 +- drivers/staging/lustre/lustre/include/obd.h| 2 +- .../staging/lustre/lustre/include/obd_support.h| 2 +- drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 4 +- drivers/staging/lustre/lustre/libcfs/fail.c| 4 +- .../lustre/lustre/libcfs/linux/linux-tracefile.c | 22 ++- drivers/staging/lustre/lustre/libcfs/tracefile.c | 4 +- drivers/staging/lustre/lustre/llite/file.c | 4 +- .../staging/lustre/lustre/llite/llite_internal.h | 2 +- drivers/staging/lustre/lustre/llite/lproc_llite.c | 2 +- drivers/staging/lustre/lustre/llite/rw.c | 6 +- drivers/staging/lustre/lustre/llite/statahead.c| 4 +- drivers/staging/lustre/lustre/llite/vvp_io.c | 2 +- drivers/staging/lustre/lustre/lmv/lmv_obd.c| 2 +- drivers/staging/lustre/lustre/lov/lov_obd.c| 4 +- drivers/staging/lustre/lustre/obdclass/capa.c | 2 +- drivers/staging/lustre/lustre/obdclass/cl_io.c | 10 +- drivers/staging/lustre/lustre/obdclass/cl_lock.c | 6 +- drivers/staging/lustre/lustre/obdclass/cl_object.c | 5 +- drivers/staging/lustre/lustre/obdclass/class_obd.c | 12 +- drivers/staging/lustre/lustre/obdclass/genops.c| 6 +- drivers/staging/lustre/lustre/obdclass/llog.c | 4 +- .../lustre/lustre/obdclass/lprocfs_counters.c | 2 +- drivers/staging/lustre/lustre/obdclass/lu_object.c | 4 +- .../staging/lustre/lustre/obdclass/obd_config.c| 6 +- drivers/staging/lustre/lustre/osc/osc_request.c| 6 +- .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 2 +- 42 files changed, 203 insertions(+), 202 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: fix whitespace errors reported by checkpatch.pl
Please ignore this one, I'm going to resend it along with some others in
a while,
Thanks.
On Wed, Aug 19, 2015 at 09:47:22AM +0300, Mike Rapoport wrote:
> Added/removed spaces and replaced '+1' with '1' in several places to eliminate
> SPACING and POINTER_LOCATION errors reported by checkpatch.pl
>
> Signed-off-by: Mike Rapoport
> ---
>
> This time with more elaborate changelog...
>
> .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 4 +-
> drivers/staging/lustre/lnet/selftest/conrpc.h | 4 +-
> drivers/staging/lustre/lnet/selftest/console.c | 16 +--
> drivers/staging/lustre/lnet/selftest/selftest.h| 2 +-
> drivers/staging/lustre/lustre/include/cl_object.h | 14 +-
> drivers/staging/lustre/lustre/include/lu_object.h | 16 +--
> .../lustre/lustre/include/lustre/lustre_idl.h | 12 +-
> .../lustre/lustre/include/lustre/lustre_user.h | 4 +-
> .../staging/lustre/lustre/include/lustre_capa.h| 2 +-
> .../staging/lustre/lustre/include/lustre_disk.h| 2 +-
> drivers/staging/lustre/lustre/include/lustre_dlm.h | 6 +-
> .../lustre/lustre/include/lustre_dlm_flags.h | 152
> ++---
> drivers/staging/lustre/lustre/include/lustre_lib.h | 6 +-
> drivers/staging/lustre/lustre/include/lustre_net.h | 2 +-
> drivers/staging/lustre/lustre/include/obd.h| 2 +-
> .../staging/lustre/lustre/include/obd_support.h| 2 +-
> drivers/staging/lustre/lustre/libcfs/tracefile.c | 4 +-
> drivers/staging/lustre/lustre/llite/file.c | 4 +-
> .../staging/lustre/lustre/llite/llite_internal.h | 2 +-
> drivers/staging/lustre/lustre/llite/lproc_llite.c | 2 +-
> drivers/staging/lustre/lustre/llite/rw.c | 6 +-
> drivers/staging/lustre/lustre/llite/statahead.c| 4 +-
> drivers/staging/lustre/lustre/llite/vvp_io.c | 2 +-
> drivers/staging/lustre/lustre/lmv/lmv_obd.c| 2 +-
> drivers/staging/lustre/lustre/lov/lov_obd.c| 4 +-
> drivers/staging/lustre/lustre/obdclass/cl_io.c | 10 +-
> drivers/staging/lustre/lustre/obdclass/cl_lock.c | 6 +-
> drivers/staging/lustre/lustre/obdclass/cl_object.c | 2 +-
> drivers/staging/lustre/lustre/obdclass/class_obd.c | 4 +-
> drivers/staging/lustre/lustre/obdclass/genops.c| 6 +-
> drivers/staging/lustre/lustre/obdclass/llog.c | 4 +-
> .../staging/lustre/lustre/obdclass/obd_config.c| 2 +-
> drivers/staging/lustre/lustre/osc/osc_request.c| 6 +-
> .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 2 +-
> 34 files changed, 159 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
> index 0d5aac6..4f9c5c8 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
> @@ -714,7 +714,7 @@ ksocknal_queue_tx_locked (ksock_tx_t *tx, ksock_conn_t
> *conn)
> LASSERT(tx->tx_resid == tx->tx_nob);
>
> CDEBUG (D_NET, "Packet %p type %d, nob %d niov %d nkiov %d\n",
> - tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type:
> + tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type :
> KSOCK_MSG_NOOP,
> tx->tx_nob, tx->tx_niov, tx->tx_nkiov);
>
> @@ -1092,7 +1092,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int
> nob_to_skip)
> conn->ksnc_rx_iov[niov].iov_len = nob;
> niov++;
> skipped += nob;
> - nob_to_skip -=nob;
> + nob_to_skip -= nob;
>
> } while (nob_to_skip != 0 &&/* mustn't overflow conn's rx iov */
>niov < sizeof(conn->ksnc_rx_iov_space) / sizeof (struct
> iovec));
> diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.h
> b/drivers/staging/lustre/lnet/selftest/conrpc.h
> index 7d33cf9..ae7ed75 100644
> --- a/drivers/staging/lustre/lnet/selftest/conrpc.h
> +++ b/drivers/staging/lustre/lnet/selftest/conrpc.h
> @@ -105,8 +105,8 @@ typedef struct lstcon_rpc_trans {
>
> #define LST_TRANS_STATQRY 0x21
>
> -typedef int (* lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
> -typedef int (* lstcon_rpc_readent_func_t)(int, srpc_msg_t *,
> lstcon_rpc_ent_t *);
> +typedef int (*lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
> +typedef int (*lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t
> *);
>
> int lstcon_sesrpc_prep(struct lstcon_node *nd, int transop,
> unsigned version, lstcon_rpc_t **crpc);
> diff --git a/drivers/staging/lustre/lnet/selftest/console.c
> b/drivers/staging/lustre/lnet/selftest/console.c
> index f47c8f2..5c624e1 100644
> --- a/drivers/staging/lustre/lnet/selftest/console.c
> +++ b/drivers/staging/lustre/lnet/selftest/console.c
> @@ -308,7 +308,7 @@ lstcon_group_ndlink_release(lstcon_group_t *grp,
> lstcon_ndlink_t *ndl)
>
Regarding USER_HZ and the exposure of kernel jiffies in userspace
Hello, I submitted a bug report a couple months ago regarding the exposure of unscaled kernel jiffies in the /proc/timer_list file (see http://bugzilla.kernel.org/show_bug.cgi?id=99401): > I noticed that the “jiffies” line from the /proc/timer_list file has a > value that is not scaled via the USER_HZ constant. Looking into the > source code of the kernel/time/timer_list.c file, I found lines > 189-190 to be the cause: > > SEQ_printf(m, "jiffies: %Lu\n", > (unsigned long long)jiffies); > > The actual kernel jiffies are printed out directly without scaling. I > was under the impression that all kernel jiffies should be scaled via > USER_HZ -- e.g. through the jiffies_to_clock_t function provided by > include/linux/jiffies.h -- before exposure in userspace. There has been no response since, and the behavior is still present in Linux version 4.1.6, so I suspect my understanding is faulty and the exposure of unscaled kernel jiffies is in fact intentional behavior. I would like to understand why this behavior is intentional, and correct my faulty impression of the design. Here's my understanding so far, please let me know where I go wrong: The Linux kernel used to have HZ set at a constant 100 for all architectures. As additional architecture support was added, the HZ value became variable: e.g. Linux on one machine could have a HZ value of 1000 while Linux on another machine could have a HZ value of 100. This possibility of a variable HZ value caused existing user code, which had hardcoded an expectation of HZ set to 100, to break due to the exposure in userspace of kernel jiffies which may have be based on a HZ value that was not equal to 100. To prevent the chaos that would occur from years of existing user code hardcoding a constant HZ value of 100, a compromise was made: any exposure of kernel jiffies to userspace should be scaled via a new USER_HZ value -- thus preventing existing user code from breaking on machines with a different HZ value, while still allowing the kernel on those machines to have a HZ value different from the historic 100 value. I believe the error in my understanding is the assumption that _all_ instances of kernel jiffies exposure in userspace should be scaled; but it appears that not all instances are. When are kernel jiffies meant to be scaled via USER_HZ, and when are they not? Thanks, William Breathitt Gray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:mm/kasan] x86/kasan, mm: Introduce generic kasan_populate_zero_shadow()
Commit-ID: 69786cdb379bbc6eab14cf2393c1abd879316e85
Gitweb: http://git.kernel.org/tip/69786cdb379bbc6eab14cf2393c1abd879316e85
Author: Andrey Ryabinin
AuthorDate: Thu, 13 Aug 2015 08:37:24 +0300
Committer: Ingo Molnar
CommitDate: Sat, 22 Aug 2015 14:54:55 +0200
x86/kasan, mm: Introduce generic kasan_populate_zero_shadow()
Introduce generic kasan_populate_zero_shadow(shadow_start,
shadow_end). This function maps kasan_zero_page to the
[shadow_start, shadow_end] addresses.
This replaces x86_64 specific populate_zero_shadow() and will
be used for ARM64 in follow on patches.
The main changes from original version are:
* Use p?d_populate*() instead of set_p?d()
* Use memblock allocator directly instead of vmemmap_alloc_block()
* __pa() instead of __pa_nodebug(). __pa() causes troubles
iff we use it before kasan_early_init(). kasan_populate_zero_shadow()
will be used later, so we ok with __pa() here.
Signed-off-by: Andrey Ryabinin
Acked-by: Catalin Marinas
Cc: Alexander Potapenko
Cc: Alexey Klimov
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Arnd Bergmann
Cc: David Keitel
Cc: Dmitry Vyukov
Cc: Linus Torvalds
Cc: Linus Walleij
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yury
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@kvack.org
Link:
http://lkml.kernel.org/r/1439444244-26057-3-git-send-email-ryabinin@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/kasan_init_64.c | 123 ++-
include/linux/kasan.h | 9 +++
mm/kasan/Makefile | 2 +-
mm/kasan/kasan_init.c | 152
4 files changed, 167 insertions(+), 119 deletions(-)
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index e1840f3..9ce5da2 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -12,20 +12,6 @@
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern struct range pfn_mapped[E820_X_MAX];
-static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
-static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
-static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
-
-/*
- * This page used as early shadow. We don't use empty_zero_page
- * at early stages, stack instrumentation could write some garbage
- * to this page.
- * Latter we reuse it as zero shadow for large ranges of memory
- * that allowed to access, but not instrumented by kasan
- * (vmalloc/vmemmap ...).
- */
-static unsigned char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;
-
static int __init map_range(struct range *range)
{
unsigned long start;
@@ -62,106 +48,6 @@ static void __init kasan_map_early_shadow(pgd_t *pgd)
}
}
-static int __init zero_pte_populate(pmd_t *pmd, unsigned long addr,
- unsigned long end)
-{
- pte_t *pte = pte_offset_kernel(pmd, addr);
-
- while (addr + PAGE_SIZE <= end) {
- WARN_ON(!pte_none(*pte));
- set_pte(pte, __pte(__pa_nodebug(kasan_zero_page)
- | __PAGE_KERNEL_RO));
- addr += PAGE_SIZE;
- pte = pte_offset_kernel(pmd, addr);
- }
- return 0;
-}
-
-static int __init zero_pmd_populate(pud_t *pud, unsigned long addr,
- unsigned long end)
-{
- int ret = 0;
- pmd_t *pmd = pmd_offset(pud, addr);
-
- while (IS_ALIGNED(addr, PMD_SIZE) && addr + PMD_SIZE <= end) {
- WARN_ON(!pmd_none(*pmd));
- set_pmd(pmd, __pmd(__pa_nodebug(kasan_zero_pte)
- | _KERNPG_TABLE));
- addr += PMD_SIZE;
- pmd = pmd_offset(pud, addr);
- }
- if (addr < end) {
- if (pmd_none(*pmd)) {
- void *p = vmemmap_alloc_block(PAGE_SIZE, NUMA_NO_NODE);
- if (!p)
- return -ENOMEM;
- set_pmd(pmd, __pmd(__pa_nodebug(p) | _KERNPG_TABLE));
- }
- ret = zero_pte_populate(pmd, addr, end);
- }
- return ret;
-}
-
-
-static int __init zero_pud_populate(pgd_t *pgd, unsigned long addr,
- unsigned long end)
-{
- int ret = 0;
- pud_t *pud = pud_offset(pgd, addr);
-
- while (IS_ALIGNED(addr, PUD_SIZE) && addr + PUD_SIZE <= end) {
- WARN_ON(!pud_none(*pud));
- set_pud(pud, __pud(__pa_nodebug(kasan_zero_pmd)
- | _KERNPG_TABLE));
- addr += PUD_SIZE;
- pud = pud_offset(pgd, addr);
- }
-
- if (addr < end) {
- if (pud_none(*pud)) {
- void *p = vmemmap_alloc_block(PAGE_SIZE, NUMA_NO_NODE);
- if (!p)
- return -ENOMEM;
- set_pud(pud, __pud(__pa_nodebug(p) |
[tip:mm/kasan] x86/kasan: Define KASAN_SHADOW_OFFSET per architecture
Commit-ID: 920e277e17f12870188f4564887a95ae9ac03e31 Gitweb: http://git.kernel.org/tip/920e277e17f12870188f4564887a95ae9ac03e31 Author: Andrey Ryabinin AuthorDate: Thu, 13 Aug 2015 08:37:23 +0300 Committer: Ingo Molnar CommitDate: Sat, 22 Aug 2015 14:54:55 +0200 x86/kasan: Define KASAN_SHADOW_OFFSET per architecture Current definition of KASAN_SHADOW_OFFSET in include/linux/kasan.h will not work for upcomming arm64, so move it to the arch header. Signed-off-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Alexey Klimov Cc: Andrew Morton Cc: Aneesh Kumar K.V Cc: Arnd Bergmann Cc: Catalin Marinas Cc: David Keitel Cc: Dmitry Vyukov Cc: Linus Torvalds Cc: Linus Walleij Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Will Deacon Cc: Yury Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@kvack.org Link: http://lkml.kernel.org/r/1439444244-26057-2-git-send-email-ryabinin@gmail.com Signed-off-by: Ingo Molnar --- arch/x86/include/asm/kasan.h | 3 +++ include/linux/kasan.h| 1 - 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index 74a2a8d..1410b56 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -1,6 +1,9 @@ #ifndef _ASM_X86_KASAN_H #define _ASM_X86_KASAN_H +#include +#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) + /* * Compiler uses shadow offset assuming that addresses start * from 0. Kernel addresses don't start from 0, so shadow diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 5486d77..6fb1c7d 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -10,7 +10,6 @@ struct vm_struct; #ifdef CONFIG_KASAN #define KASAN_SHADOW_SCALE_SHIFT 3 -#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/asm/delay: Introduce an MWAITX-based delay with a configurable timer
Commit-ID: b466bdb6148237188e85516177d2850f4782
Gitweb: http://git.kernel.org/tip/b466bdb6148237188e85516177d2850f4782
Author: Huang Rui
AuthorDate: Mon, 10 Aug 2015 12:19:54 +0200
Committer: Ingo Molnar
CommitDate: Sat, 22 Aug 2015 14:52:16 +0200
x86/asm/delay: Introduce an MWAITX-based delay with a configurable timer
MWAITX can enable a timer and a corresponding timer value
specified in SW P0 clocks. The SW P0 frequency is the same as
TSC. The timer provides an upper bound on how long the
instruction waits before exiting.
This way, a delay function in the kernel can leverage that
MWAITX timer of MWAITX.
When a CPU core executes MWAITX, it will be quiesced in a
waiting phase, diminishing its power consumption. This way, we
can save power in comparison to our default TSC-based delays.
A simple test shows that:
$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
$ sleep 1s
$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
Results:
* TSC-based default delay: 485115 uWatts average power
* MWAITX-based delay: 252738 uWatts average power
Thus, that's about 240 milliWatts less power consumption. The
test method relies on the support of AMD CPU accumulated power
algorithm in fam15h_power for which patches are forthcoming.
Suggested-by: Andy Lutomirski
Suggested-by: Borislav Petkov
Suggested-by: Peter Zijlstra
Signed-off-by: Huang Rui
[ Fix delay truncation. ]
Signed-off-by: Borislav Petkov
Cc: Aaron Lu
Cc: Andreas Herrmann
Cc: Aravind Gopalakrishnan
Cc: Fengguang Wu
Cc: Frédéric Weisbecker
Cc: H. Peter Anvin
Cc: Hector Marco-Gisbert
Cc: Jacob Shin
Cc: Jiri Olsa
Cc: John Stultz
Cc: Len Brown
Cc: Linus Torvalds
Cc: Paolo Bonzini
Cc: Rafael J. Wysocki
Cc: Thomas Gleixner
Cc: Tony Li
Link:
http://lkml.kernel.org/r/1438744732-1459-3-git-send-email-ray.hu...@amd.com
Link: http://lkml.kernel.org/r/1439201994-28067-4-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/delay.h | 1 +
arch/x86/kernel/cpu/amd.c| 4
arch/x86/lib/delay.c | 47 +++-
3 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/delay.h b/arch/x86/include/asm/delay.h
index 9b3b4f2..36a760b 100644
--- a/arch/x86/include/asm/delay.h
+++ b/arch/x86/include/asm/delay.h
@@ -4,5 +4,6 @@
#include
void use_tsc_delay(void);
+void use_mwaitx_delay(void);
#endif /* _ASM_X86_DELAY_H */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 51ad2af..4a70fc6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_64
# include
@@ -506,6 +507,9 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
/* A random value per boot for bit slice [12:upper_bit) */
va_align.bits = get_random_int() & va_align.mask;
}
+
+ if (cpu_has(c, X86_FEATURE_MWAITX))
+ use_mwaitx_delay();
}
static void early_init_amd(struct cpuinfo_x86 *c)
diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c
index 4453d52..e912b2f 100644
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_SMP
# include
@@ -84,6 +85,44 @@ static void delay_tsc(unsigned long __loops)
}
/*
+ * On some AMD platforms, MWAITX has a configurable 32-bit timer, that
+ * counts with TSC frequency. The input value is the loop of the
+ * counter, it will exit when the timer expires.
+ */
+static void delay_mwaitx(unsigned long __loops)
+{
+ u64 start, end, delay, loops = __loops;
+
+ start = rdtsc_ordered();
+
+ for (;;) {
+ delay = min_t(u64, MWAITX_MAX_LOOPS, loops);
+
+ /*
+* Use cpu_tss as a cacheline-aligned, seldomly
+* accessed per-cpu variable as the monitor target.
+*/
+ __monitorx(this_cpu_ptr(_tss), 0, 0);
+
+ /*
+* AMD, like Intel, supports the EAX hint and EAX=0xf
+* means, do not enter any deep C-state and we use it
+* here in delay() to minimize wakeup latency.
+*/
+ __mwaitx(MWAITX_DISABLE_CSTATES, delay,
MWAITX_ECX_TIMER_ENABLE);
+
+ end = rdtsc_ordered();
+
+ if (loops <= end - start)
+ break;
+
+ loops -= end - start;
+
+ start = end;
+ }
+}
+
+/*
* Since we calibrate only once at boot, this
* function should be set once at boot and not changed
*/
@@ -91,7 +130,13 @@ static void (*delay_fn)(unsigned long) = delay_loop;
void use_tsc_delay(void)
{
- delay_fn = delay_tsc;
+ if (delay_fn == delay_loop)
+ delay_fn = delay_tsc;
+}
+
+void use_mwaitx_delay(void)
+{
+
[tip:x86/asm] x86/asm: Add MONITORX/MWAITX instruction support
Commit-ID: f96756746c7909de37db3d03ac5fd5cfb2757f38
Gitweb: http://git.kernel.org/tip/f96756746c7909de37db3d03ac5fd5cfb2757f38
Author: Huang Rui
AuthorDate: Mon, 10 Aug 2015 12:19:53 +0200
Committer: Ingo Molnar
CommitDate: Sat, 22 Aug 2015 14:52:16 +0200
x86/asm: Add MONITORX/MWAITX instruction support
AMD Carrizo processors (Family 15h, Models 60h-6fh) added a new
feature called MWAITX (MWAIT with extensions) as an extension to
MONITOR/MWAIT.
This new instruction controls a configurable timer which causes
the core to exit wait state on timer expiration, in addition to
"normal" MWAIT condition of reading from a monitored VA.
Compared to MONITOR/MWAIT, there are minor differences in opcode
and input parameters:
MWAITX ECX[1]: enable timer if set
MWAITX EBX[31:0]: max wait time expressed in SW P0 clocks ==
TSC. The software P0 frequency is the same as the TSC frequency.
MWAIT MWAITX
opcode 0f 01 c9 |0f 01 fb
ECX[0] value of RFLAGS.IF seen by instruction
ECX[1] unused/#GP if set |enable timer if set
ECX[31:2] unused/#GP if set
EAX unused (reserve for hint)
EBX[31:0] unused |max wait time (SW P0 == TSC)
MONITOR MONITORX
opcode 0f 01 c8 |0f 01 fa
EAX (logical) address to monitor
ECX #GP if not zero
Max timeout = EBX/(TSC frequency)
Signed-off-by: Huang Rui
Signed-off-by: Borislav Petkov
Cc: Aaron Lu
Cc: Alexander Shishkin
Cc: Andreas Herrmann
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Dirk Brandewie
Cc: Fengguang Wu
Cc: Frédéric Weisbecker
Cc: H. Peter Anvin
Cc: John Stultz
Cc: Josh Triplett
Cc: Len Brown
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Ross Zwisler
Cc: Thomas Gleixner
Cc: Tony Li
Link: http://lkml.kernel.org/r/1439201994-28067-3-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/mwait.h | 45 +++
2 files changed, 46 insertions(+)
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 3d6606f..a39e570 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -176,6 +176,7 @@
#define X86_FEATURE_PERFCTR_NB ( 6*32+24) /* NB performance counter
extensions */
#define X86_FEATURE_BPEXT (6*32+26) /* data breakpoint extension */
#define X86_FEATURE_PERFCTR_L2 ( 6*32+28) /* L2 performance counter extensions
*/
+#define X86_FEATURE_MWAITX ( 6*32+29) /* MWAIT extension (MONITORX/MWAITX)
*/
/*
* Auxiliary flags: Linux defined - For features scattered in various
diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
index 653dfa7..c70689b 100644
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -14,6 +14,9 @@
#define CPUID5_ECX_INTERRUPT_BREAK 0x2
#define MWAIT_ECX_INTERRUPT_BREAK 0x1
+#define MWAITX_ECX_TIMER_ENABLEBIT(1)
+#define MWAITX_MAX_LOOPS ((u32)-1)
+#define MWAITX_DISABLE_CSTATES 0xf
static inline void __monitor(const void *eax, unsigned long ecx,
unsigned long edx)
@@ -23,6 +26,14 @@ static inline void __monitor(const void *eax, unsigned long
ecx,
:: "a" (eax), "c" (ecx), "d"(edx));
}
+static inline void __monitorx(const void *eax, unsigned long ecx,
+ unsigned long edx)
+{
+ /* "monitorx %eax, %ecx, %edx;" */
+ asm volatile(".byte 0x0f, 0x01, 0xfa;"
+:: "a" (eax), "c" (ecx), "d"(edx));
+}
+
static inline void __mwait(unsigned long eax, unsigned long ecx)
{
/* "mwait %eax, %ecx;" */
@@ -30,6 +41,40 @@ static inline void __mwait(unsigned long eax, unsigned long
ecx)
:: "a" (eax), "c" (ecx));
}
+/*
+ * MWAITX allows for a timer expiration to get the core out a wait state in
+ * addition to the default MWAIT exit condition of a store appearing at a
+ * monitored virtual address.
+ *
+ * Registers:
+ *
+ * MWAITX ECX[1]: enable timer if set
+ * MWAITX EBX[31:0]: max wait time expressed in SW P0 clocks. The software P0
+ * frequency is the same as the TSC frequency.
+ *
+ * Below is a comparison between MWAIT and MWAITX on AMD processors:
+ *
+ * MWAIT MWAITX
+ * opcode 0f 01 c9 |0f 01 fb
+ * ECX[0] value of RFLAGS.IF seen by instruction
+ * ECX[1] unused/#GP if set |enable timer if set
+ * ECX[31:2] unused/#GP if set
+ * EAX unused (reserve for hint)
+ * EBX[31:0] unused |max wait time (P0 clocks)
+ *
+ *
[tip:core/core] x86/traps: Weaken context tracking entry assertions
Commit-ID: f0a97af83f6287357dcc100c859ec0066f164f32
Gitweb: http://git.kernel.org/tip/f0a97af83f6287357dcc100c859ec0066f164f32
Author: Andy Lutomirski
AuthorDate: Thu, 20 Aug 2015 22:03:21 -0700
Committer: Ingo Molnar
CommitDate: Sat, 22 Aug 2015 11:12:10 +0200
x86/traps: Weaken context tracking entry assertions
We were asserting that we were all the way in CONTEXT_KERNEL
when exception handlers were called. While having this be true
is, I think, a nice goal (or maybe a variant in which we assert
that we're in CONTEXT_KERNEL or some new IRQ context), we're not
quite there.
In particular, if an IRQ interrupts the SYSCALL prologue and the
IRQ handler in turn causes an exception, the exception entry
will be called in RCU IRQ mode but with CONTEXT_USER.
This is okay (nothing goes wrong), but until we fix up the
SYSCALL prologue, we need to avoid warning.
Signed-off-by: Andy Lutomirski
Acked-by: Frederic Weisbecker
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/c81faf3916346c0e04346c441392974f49cd7184.1440133286.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/traps.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 86a82ea..45e8d98 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -112,7 +112,7 @@ static inline void preempt_conditional_cli(struct pt_regs
*regs)
void ist_enter(struct pt_regs *regs)
{
if (user_mode(regs)) {
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake
RCU");
} else {
/*
* We might have interrupted pretty much anything. In
@@ -282,7 +282,7 @@ static void do_error_trap(struct pt_regs *regs, long
error_code, char *str,
{
siginfo_t info;
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
@@ -364,7 +364,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long
error_code)
const struct bndcsr *bndcsr;
siginfo_t *info;
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
return;
@@ -442,7 +442,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
{
struct task_struct *tsk;
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
conditional_sti(regs);
if (v8086_mode(regs)) {
@@ -496,7 +496,7 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs,
long error_code)
return;
ist_enter(regs);
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
SIGTRAP) == NOTIFY_STOP)
@@ -729,14 +729,14 @@ static void math_error(struct pt_regs *regs, int
error_code, int trapnr)
dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code)
{
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
math_error(regs, error_code, X86_TRAP_MF);
}
dotraplinkage void
do_simd_coprocessor_error(struct pt_regs *regs, long error_code)
{
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
math_error(regs, error_code, X86_TRAP_XF);
}
@@ -749,7 +749,7 @@ do_spurious_interrupt_bug(struct pt_regs *regs, long
error_code)
dotraplinkage void
do_device_not_available(struct pt_regs *regs, long error_code)
{
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
BUG_ON(use_eager_fpu());
#ifdef CONFIG_MATH_EMULATION
@@ -775,7 +775,7 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long
error_code)
{
siginfo_t info;
- CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+ rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
local_irq_enable();
info.si_signo = SIGILL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
[tip:x86/microcode] x86/microcode: Use kmemdup() rather than duplicating its implementation
Commit-ID: d4e963644768b33aa3db7f470c35d74ed78d8354
Gitweb: http://git.kernel.org/tip/d4e963644768b33aa3db7f470c35d74ed78d8354
Author: Andrzej Hajda
AuthorDate: Mon, 10 Aug 2015 12:19:52 +0200
Committer: Ingo Molnar
CommitDate: Sat, 22 Aug 2015 14:49:35 +0200
x86/microcode: Use kmemdup() rather than duplicating its implementation
The patch was generated using fixed coccinelle semantic patch
scripts/coccinelle/api/memdup.cocci.
Signed-off-by: Andrzej Hajda
Signed-off-by: Borislav Petkov
Cc: Bartlomiej Zolnierkiewicz
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Marek Szyprowski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1439201994-28067-2-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/microcode/amd.c | 4 +---
arch/x86/kernel/cpu/microcode/intel_early.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index c7d2415..be37f10 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -366,15 +366,13 @@ static int verify_and_add_patch(u8 family, u8 *fw,
unsigned int leftover)
return -EINVAL;
}
- patch->data = kzalloc(patch_size, GFP_KERNEL);
+ patch->data = kmemdup(fw + SECTION_HDR_SIZE, patch_size, GFP_KERNEL);
if (!patch->data) {
pr_err("Patch data allocation failure.\n");
kfree(patch);
return -EINVAL;
}
- /* All looks ok, copy patch... */
- memcpy(patch->data, fw + SECTION_HDR_SIZE, patch_size);
INIT_LIST_HEAD(>plist);
patch->patch_id = mc_hdr->patch_id;
patch->equiv_cpu = proc_id;
diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c
b/arch/x86/kernel/cpu/microcode/intel_early.c
index 8187b72..101f0ac 100644
--- a/arch/x86/kernel/cpu/microcode/intel_early.c
+++ b/arch/x86/kernel/cpu/microcode/intel_early.c
@@ -207,13 +207,11 @@ save_microcode(struct mc_saved_data *mc_saved_data,
mc_hdr = >hdr;
size = get_totalsize(mc_hdr);
- saved_ptr[i] = kmalloc(size, GFP_KERNEL);
+ saved_ptr[i] = kmemdup(mc, size, GFP_KERNEL);
if (!saved_ptr[i]) {
ret = -ENOMEM;
goto err;
}
-
- memcpy(saved_ptr[i], mc, size);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
