Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Thierry Reding]

On Fri, Feb 24, 2017 at 10:51:12AM +0100, Lucas Stach wrote:
> +CC Thierry, as the drm_panel maintainer.
> 
> Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul:
> > On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> > > > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > > > > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> > > > >> The panels shipped with Allwinner devices are very "generic", i.e.
> > > > >> they do not have model numbers or reliable sources of information
> > > > >> for the timings (that we know of) other than the fex files shipped
> > > > >> on them. The dot clock frequency provided in the fex files have all
> > > > >> been rounded to the nearest MHz, as that is the unit used in them.
> > > > >> 
> > > > >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> > > > >> for the A13 Q8 tablets in the absence of a specific model for what
> > > > >> may be many different but otherwise timing compatible panels. This
> > > > >> was usable without any visual artifacts or side effects, until the
> > > > >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> > > > >> rgb: Validate the clock rate").
> > > > >> 
> > > > >> The reason this check fails is because the dotclock frequency for
> > > > >> this model is 33.26 MHz, which is not achievable with our dot clock
> > > > >> hardware, and the rate returned by clk_round_rate deviates slightly,
> > > > >> causing the driver to reject the display mode.
> > > > >> 
> > > > >> The LCD panels have some tolerance on the dot clock frequency, even
> > > > >> if it's not specified in their datasheets.
> > > > >> 
> > > > >> This patch adds a 5% tolerence to the dot clock check.
> > > > > 
> > > > > As we discussed already, I really believe this is just as arbitrary as
> > > > > the current behaviour.
> > > > 
> > > > Yes. I agree. This patch is mainly to give something that works for
> > > > people who don't care about the details, and to get some feedback
> > > > from people that do.
> > > > 
> > > > > Some panels require an exact frequency,
> > > 
> > > There's no such thing as an exact frequency, there will always be some 
> > > tolerance (and if your display controller can really generate an exact 
> > > frequency I'd be very interested in that hardware :-)).
> > 
> > There is such thing as exact frequency when you have to worry about panel
> > warranty. We are fortunate, since we can talk to the panel manufacturer and
> > discuss which frequencies are tolerable inside the warranty. We usually hand
> > pick a rate/mode within these constraints.
> > 
> > Also, even though things *look* ok on the panel at a certain clock rate, 
> > running
> > outside the specified clock could damage the hardware.
> > 
> > I don't think it's unreasonable to add tolerances to drm_panel, since they 
> > will
> > differ in what is acceptable. The tricky part is teasing out what the 
> > tolerances
> > are.
> 
> The drm_panel already allows to specify all panel timings in pairs of
> min/typical/max. Just use this instead of some arbitrary tolerance.
> 
> I know most panels currently only expose a fixed mode, but it's not hard
> to convert this into a display_timing if you can get hold of the display
> datasheet. A lot of the panel datasheets I had to deal with lately
> actually specify all the required information. Most of the time you need
> to sanity check things, as most vendors seem to produce them by "copy
> the last datasheet we made and change only necessary fields", but that
> really isn't a hard job.

Agreed. Back at the time support for min/typ/max timings was introduced
specifically to address such issues. Conversion to those timings from a
fixed mode is as simple as making min = max = typ, where typ is the DRM
display mode value.

There's a helper that will return a DRM display mode based on the
typical values for drivers that don't care (i.e. most) and drivers that
do care can simply use the timings directly and adjust as necessary. It
would be rather backwards to add tolerances to display drivers, because
that's not where the tolerances are defined. Panels impose the
restrictions, so it should be panel drivers that contain the data.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Thierry Reding]

On Fri, Feb 24, 2017 at 10:51:12AM +0100, Lucas Stach wrote:
> +CC Thierry, as the drm_panel maintainer.
> 
> Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul:
> > On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> > > > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > > > > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> > > > >> The panels shipped with Allwinner devices are very "generic", i.e.
> > > > >> they do not have model numbers or reliable sources of information
> > > > >> for the timings (that we know of) other than the fex files shipped
> > > > >> on them. The dot clock frequency provided in the fex files have all
> > > > >> been rounded to the nearest MHz, as that is the unit used in them.
> > > > >> 
> > > > >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> > > > >> for the A13 Q8 tablets in the absence of a specific model for what
> > > > >> may be many different but otherwise timing compatible panels. This
> > > > >> was usable without any visual artifacts or side effects, until the
> > > > >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> > > > >> rgb: Validate the clock rate").
> > > > >> 
> > > > >> The reason this check fails is because the dotclock frequency for
> > > > >> this model is 33.26 MHz, which is not achievable with our dot clock
> > > > >> hardware, and the rate returned by clk_round_rate deviates slightly,
> > > > >> causing the driver to reject the display mode.
> > > > >> 
> > > > >> The LCD panels have some tolerance on the dot clock frequency, even
> > > > >> if it's not specified in their datasheets.
> > > > >> 
> > > > >> This patch adds a 5% tolerence to the dot clock check.
> > > > > 
> > > > > As we discussed already, I really believe this is just as arbitrary as
> > > > > the current behaviour.
> > > > 
> > > > Yes. I agree. This patch is mainly to give something that works for
> > > > people who don't care about the details, and to get some feedback
> > > > from people that do.
> > > > 
> > > > > Some panels require an exact frequency,
> > > 
> > > There's no such thing as an exact frequency, there will always be some 
> > > tolerance (and if your display controller can really generate an exact 
> > > frequency I'd be very interested in that hardware :-)).
> > 
> > There is such thing as exact frequency when you have to worry about panel
> > warranty. We are fortunate, since we can talk to the panel manufacturer and
> > discuss which frequencies are tolerable inside the warranty. We usually hand
> > pick a rate/mode within these constraints.
> > 
> > Also, even though things *look* ok on the panel at a certain clock rate, 
> > running
> > outside the specified clock could damage the hardware.
> > 
> > I don't think it's unreasonable to add tolerances to drm_panel, since they 
> > will
> > differ in what is acceptable. The tricky part is teasing out what the 
> > tolerances
> > are.
> 
> The drm_panel already allows to specify all panel timings in pairs of
> min/typical/max. Just use this instead of some arbitrary tolerance.
> 
> I know most panels currently only expose a fixed mode, but it's not hard
> to convert this into a display_timing if you can get hold of the display
> datasheet. A lot of the panel datasheets I had to deal with lately
> actually specify all the required information. Most of the time you need
> to sanity check things, as most vendors seem to produce them by "copy
> the last datasheet we made and change only necessary fields", but that
> really isn't a hard job.

Agreed. Back at the time support for min/typ/max timings was introduced
specifically to address such issues. Conversion to those timings from a
fixed mode is as simple as making min = max = typ, where typ is the DRM
display mode value.

There's a helper that will return a DRM display mode based on the
typical values for drivers that don't care (i.e. most) and drivers that
do care can simply use the timings directly and adjust as necessary. It
would be rather backwards to add tolerances to display drivers, because
that's not where the tolerances are defined. Panels impose the
restrictions, so it should be panel drivers that contain the data.

Thierry


signature.asc
Description: PGP signature

Re: [linux-sunxi] [PATCH 2/3] pwm: sunxi: Add A64 support

[Maxime Ripard]

On Sat, Feb 25, 2017 at 05:23:09PM +0800, Icenowy Zheng wrote:
> 
> 
> 25.02.2017, 16:53, "Chen-Yu Tsai" :
> > On Sat, Feb 25, 2017 at 3:42 PM, Icenowy Zheng  wrote:
> >>  A64 PWM controller has same register layout as sun4i driver, so it works
> >>  by adding A64 specific data.
> >>
> >>  Signed-off-by: Icenowy Zheng 
> >>  ---
> >>   drivers/pwm/pwm-sun4i.c | 9 +
> >>   1 file changed, 9 insertions(+)
> >>
> >>  diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> >>  index 1284ffa05921..ca3431e03fb8 100644
> >>  --- a/drivers/pwm/pwm-sun4i.c
> >>  +++ b/drivers/pwm/pwm-sun4i.c
> >>  @@ -290,6 +290,12 @@ static const struct sun4i_pwm_data sun4i_pwm_data_h3 
> >> = {
> >>  .npwm = 1,
> >>   };
> >>
> >>  +static const struct sun4i_pwm_data sun4i_pwm_data_a64 = {
> >>  + .has_prescaler_bypass = true,
> >>  + .has_rdy = true,
> >>  + .npwm = 1,
> >>  +};
> >>  +
> >
> > This seems to be tha same as the H3. Any differences between the
> > H3 and A64? Otherwise please just use that compatible.
> 
> H3 is also same as A13...
> 
> See 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486595.html

What I meant was that you should have a compatible in your DT like this:

compatible = "allwinner,sun50i-a64-pwm", "allwinner,sun5i-a13-pwm".

There's no need to add a new one in the driver (for now).

And you still haven't fixed the size.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] [PATCH 2/3] pwm: sunxi: Add A64 support

[Maxime Ripard]

On Sat, Feb 25, 2017 at 05:23:09PM +0800, Icenowy Zheng wrote:
> 
> 
> 25.02.2017, 16:53, "Chen-Yu Tsai" :
> > On Sat, Feb 25, 2017 at 3:42 PM, Icenowy Zheng  wrote:
> >>  A64 PWM controller has same register layout as sun4i driver, so it works
> >>  by adding A64 specific data.
> >>
> >>  Signed-off-by: Icenowy Zheng 
> >>  ---
> >>   drivers/pwm/pwm-sun4i.c | 9 +
> >>   1 file changed, 9 insertions(+)
> >>
> >>  diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> >>  index 1284ffa05921..ca3431e03fb8 100644
> >>  --- a/drivers/pwm/pwm-sun4i.c
> >>  +++ b/drivers/pwm/pwm-sun4i.c
> >>  @@ -290,6 +290,12 @@ static const struct sun4i_pwm_data sun4i_pwm_data_h3 
> >> = {
> >>  .npwm = 1,
> >>   };
> >>
> >>  +static const struct sun4i_pwm_data sun4i_pwm_data_a64 = {
> >>  + .has_prescaler_bypass = true,
> >>  + .has_rdy = true,
> >>  + .npwm = 1,
> >>  +};
> >>  +
> >
> > This seems to be tha same as the H3. Any differences between the
> > H3 and A64? Otherwise please just use that compatible.
> 
> H3 is also same as A13...
> 
> See 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486595.html

What I meant was that you should have a compatible in your DT like this:

compatible = "allwinner,sun50i-a64-pwm", "allwinner,sun5i-a13-pwm".

There's no need to add a new one in the driver (for now).

And you still haven't fixed the size.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration

[Huang, Kai]

On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote:



On 2017/2/24 23:14, Paolo Bonzini wrote:



On 24/02/2017 16:10, Chris Friesen wrote:

On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote:


On 2017/2/22 22:43, Paolo Bonzini wrote:



Hopefully Gaohuai and Rongguang can help with this too.

Paolo


Yes, we are looking into and testing this.

I think this can result in any memory corruption, if VM1 writes its
PML buffer into VM2’s VMCS (since sched_in/sched_out notifier of VM1
is not registered yet), then VM1 is destroyed (hence its PML buffer
is freed back to kernel), after that, VM2 starts migration, so CPU
logs VM2’s dirty GFNS into a freed memory, results in any memory
corruption.

As its severity, this commit
(http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4e59516a12a6ef6dcb660cb3a3f70c64bd60cfec)


is eligible to back port to kernel stable.


Are we expecting that fix to resolve the original issue, or is it a
separate issue that needs fixing in stable?


It should be the original issue.

Paolo

.


Yes, I agree, though we are still testing.



Hi Stephen,

Sorry for late reply. I was taking the whole week off last week. How's 
the test going?


Thanks,
-Kai

Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration

[Huang, Kai]

On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote:



On 2017/2/24 23:14, Paolo Bonzini wrote:



On 24/02/2017 16:10, Chris Friesen wrote:

On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote:


On 2017/2/22 22:43, Paolo Bonzini wrote:



Hopefully Gaohuai and Rongguang can help with this too.

Paolo


Yes, we are looking into and testing this.

I think this can result in any memory corruption, if VM1 writes its
PML buffer into VM2’s VMCS (since sched_in/sched_out notifier of VM1
is not registered yet), then VM1 is destroyed (hence its PML buffer
is freed back to kernel), after that, VM2 starts migration, so CPU
logs VM2’s dirty GFNS into a freed memory, results in any memory
corruption.

As its severity, this commit
(http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4e59516a12a6ef6dcb660cb3a3f70c64bd60cfec)


is eligible to back port to kernel stable.


Are we expecting that fix to resolve the original issue, or is it a
separate issue that needs fixing in stable?


It should be the original issue.

Paolo

.


Yes, I agree, though we are still testing.



Hi Stephen,

Sorry for late reply. I was taking the whole week off last week. How's 
the test going?


Thanks,
-Kai

Re: [PATCH 0/7] net: stmmac: Fixes and Tegra186 support

[Thierry Reding]

On Thu, Feb 23, 2017 at 12:57:05PM -0500, David Miller wrote:
> 
> The net-next tree is closed, therefore it is not appropriate to submit
> feature patches or cleanups at this time.
> 
> Please wait for the merge window to be finished and the net-next tree
> to open back up before resubmitting this patch series.

Okay, I'll resend this after the merge window. In the meantime, surely
it's okay for others to review patches?

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 0/7] net: stmmac: Fixes and Tegra186 support

[Thierry Reding]

On Thu, Feb 23, 2017 at 12:57:05PM -0500, David Miller wrote:
> 
> The net-next tree is closed, therefore it is not appropriate to submit
> feature patches or cleanups at this time.
> 
> Please wait for the merge window to be finished and the net-next tree
> to open back up before resubmitting this patch series.

Okay, I'll resend this after the merge window. In the meantime, surely
it's okay for others to review patches?

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

[Gautham R Shenoy]

Hi Anton,
On Mon, Feb 27, 2017 at 10:37:07AM +1100, Anton Blanchard wrote:
> Hi Gautham,
> 
> > +handle_esl_ec_set:
> 
> Unless we want to expose this to things like perf, we might want to
> make it a local label (eg .Lxx)

Sure. We don't want to expose this to perf at least as of now! Will
resend the patch with a local label.
> 
> Anton
>

--
Thanks and Regards
gautham.

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

[Gautham R Shenoy]

Hi Anton,
On Mon, Feb 27, 2017 at 10:37:07AM +1100, Anton Blanchard wrote:
> Hi Gautham,
> 
> > +handle_esl_ec_set:
> 
> Unless we want to expose this to things like perf, we might want to
> make it a local label (eg .Lxx)

Sure. We don't want to expose this to perf at least as of now! Will
resend the patch with a local label.
> 
> Anton
>

--
Thanks and Regards
gautham.

Re: [PATCH] ASoC: tegra: Remove unnecessary 'out of memory' message

[Thierry Reding]

On Sat, Feb 25, 2017 at 01:18:08PM +0200, Codrut Grosu wrote:
> This was reported by checkpatch.pl
> 
> Signed-off-by: Codrut GROSU 
> ---
>  sound/soc/tegra/tegra20_ac97.c   | 1 -
>  sound/soc/tegra/tegra20_das.c| 1 -
>  sound/soc/tegra/tegra20_i2s.c| 1 -
>  sound/soc/tegra/tegra20_spdif.c  | 5 ++---
>  sound/soc/tegra/tegra30_ahub.c   | 4 +---
>  sound/soc/tegra/tegra30_i2s.c| 1 -
>  sound/soc/tegra/tegra_alc5632.c  | 4 +---
>  sound/soc/tegra/tegra_max98090.c | 4 +---
>  sound/soc/tegra/tegra_rt5640.c   | 4 +---
>  sound/soc/tegra/tegra_sgtl5000.c | 4 +---
>  sound/soc/tegra/tegra_wm8753.c   | 4 +---
>  sound/soc/tegra/tegra_wm8903.c   | 4 +---
>  sound/soc/tegra/tegra_wm9712.c   | 4 +---
>  sound/soc/tegra/trimslice.c  | 4 +---
>  14 files changed, 11 insertions(+), 34 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH] ASoC: tegra: Remove unnecessary 'out of memory' message

[Thierry Reding]

On Sat, Feb 25, 2017 at 01:18:08PM +0200, Codrut Grosu wrote:
> This was reported by checkpatch.pl
> 
> Signed-off-by: Codrut GROSU 
> ---
>  sound/soc/tegra/tegra20_ac97.c   | 1 -
>  sound/soc/tegra/tegra20_das.c| 1 -
>  sound/soc/tegra/tegra20_i2s.c| 1 -
>  sound/soc/tegra/tegra20_spdif.c  | 5 ++---
>  sound/soc/tegra/tegra30_ahub.c   | 4 +---
>  sound/soc/tegra/tegra30_i2s.c| 1 -
>  sound/soc/tegra/tegra_alc5632.c  | 4 +---
>  sound/soc/tegra/tegra_max98090.c | 4 +---
>  sound/soc/tegra/tegra_rt5640.c   | 4 +---
>  sound/soc/tegra/tegra_sgtl5000.c | 4 +---
>  sound/soc/tegra/tegra_wm8753.c   | 4 +---
>  sound/soc/tegra/tegra_wm8903.c   | 4 +---
>  sound/soc/tegra/tegra_wm9712.c   | 4 +---
>  sound/soc/tegra/trimslice.c  | 4 +---
>  14 files changed, 11 insertions(+), 34 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH 0/4] fujitsu_init() cleanup

[Michał Kępień]

> Darren, Andy,
> 
> Please drop this patch series for now.  I will send a rebased v2 after a
> long overdue patch series from Alan Jenkins gets applied in a reworked
> form.
> 
> However, your input is still essential for determining the future shape
> of fujitsu-laptop.  I quoted the essential parts of my discussion with
> Jonathan below.
> 
> > > > The problem I have with this driver is that it is generally oblivious to
> > > > the user's chosen backlight provider.  It was written before acpi_video
> > > > support for backlight control was automatically detected by the kernel 
> > > > and as such it required a fix which was allegedly provided by  
> > > > 7d5c89a615c5 ("fujitsu-laptop: fingers off backlight if video.ko is
> > > > serving this functionality").  However, that fix was superficial as the
> > > > module still registered its vendor-specific ACPI driver for backlight  
> > > > control.  That in turn caused SBLL/SBL2 to be called when brightness   
> > > > hotkeys were pressed even when acpi_video was supposed to handle   
> > > > brightness changes, which is exactly what that patch was hoping to 
> > > > prevent.  Moreover, the module unconditionally exports backlight-related
> > > > sysfs attributes which enable userspace to change the brightness level,
> > > > which should also only be possible when vendor backlight control is
> > > > used.  Fast forward several years and on modern Fujitsu machines (e.g. 
> > > > Lifebook E744), the kernel automatically detects that native backlight 
> > > > control [1] should be used and SBLL becomes a noop [2].  This creates  
> > > > confusion, because the driver claims that it can get/set LCD brightness
> > > > level via the platform device's sysfs attributes, but it actually  
> > > > cannot.  It gets even more confusing on Skylake machines on which the  
> > > > FUJ02B1 ACPI device is not present at all. 
> 
> []
> 
> > > > The proposal I put forward in regard to the above is to remove the three
> > > > backlight-related attributes (brightness_changed, lcd_level,
> > > > max_brightness) from the platform driver's sysfs tree.  I believe the
> > > > functions they implement should only be exposed through the backlight
> > > > device, because the latter is only created when the user explicitly
> > > > selects vendor backlight control or it is automatically selected by the
> > > > kernel (this should be the case for older machines).
> > > 
> > > I will need to do some more digging into the historical developments.  At
> > > face value I'm not sure how machines like the S7020 would end up 
> > > controlling
> > > the backlight if these sysfs attributes were removed because on this 
> > > machine
> > > (at least last time I checked) the standard backlight/video drivers could
> > > not effect brightness control on this hardware.  Or is there a side effect
> > > that I have forgotten?
> > 
> > Let us not confuse three separate things that fujitsu-laptop enables:
> > 
> >   * changing LCD brightness using the keyboard,
> >   * changing LCD brightness from userspace, using the backlight device,
> >   * changing LCD brightness from userspace, using sysfs attributes.
> > 
> > I have nothing against the first two, apart from the notion that they
> > should be more tightly coupled (i.e. one should not be enabled without
> > the other one and vice versa).
> > 
> > I am all against the last one.  IMHO it is a duplicate, misplaced
> > feature which only makes clean separation of components inside the
> > driver hard.
> > 
> > > > That would leave us with the remaining three sysfs attributes of the
> > > > platform device, namely dock, lid and radios.  These all depend on the
> > > > FUJ02E3 ACPI device.  Which begs the question: shall we reassign them to
> > > > that ACPI device and drop the platform device altogether?  This would
> > > > logically be the correct thing to do (panasonic-laptop and toshiba_acpi
> > > > already assign extra sysfs attributes to ACPI nodes).  But I understand
> > > > that this would break an 8-year-old userspace interface as functions
> > > > previously exposed through /sys/devices/platform/fujitsu-laptop would be
> > > > moved to /sys/bus/acpi/devices/FUJ02E3:00.  If that is unacceptable, the
> > > > least we can (and should) do is to move platform device registration to
> > > > acpi_fujitsu_hotkey_add().  What the driver currently does may create
> > > > confusion in the future, because the platform device is registered
> > > > unconditionally while it clearly depends on FUJ02E3 being present.  I do
> > > > not know whether FUJ02E3 is present on all Fujitsu devices today without
> > > > exception, but I do know that if Fujitsu ever decides to drop that
> > > > device from its firmware, we would again (see above) expose a userspace
> > > > interface (dock, lid, radios) which simply will not be able to function
> > > > properly.
> 
> []
> 
> > > Regarding the movement of sysfs 

Re: [PATCH 0/4] fujitsu_init() cleanup

[Michał Kępień]

> Darren, Andy,
> 
> Please drop this patch series for now.  I will send a rebased v2 after a
> long overdue patch series from Alan Jenkins gets applied in a reworked
> form.
> 
> However, your input is still essential for determining the future shape
> of fujitsu-laptop.  I quoted the essential parts of my discussion with
> Jonathan below.
> 
> > > > The problem I have with this driver is that it is generally oblivious to
> > > > the user's chosen backlight provider.  It was written before acpi_video
> > > > support for backlight control was automatically detected by the kernel 
> > > > and as such it required a fix which was allegedly provided by  
> > > > 7d5c89a615c5 ("fujitsu-laptop: fingers off backlight if video.ko is
> > > > serving this functionality").  However, that fix was superficial as the
> > > > module still registered its vendor-specific ACPI driver for backlight  
> > > > control.  That in turn caused SBLL/SBL2 to be called when brightness   
> > > > hotkeys were pressed even when acpi_video was supposed to handle   
> > > > brightness changes, which is exactly what that patch was hoping to 
> > > > prevent.  Moreover, the module unconditionally exports backlight-related
> > > > sysfs attributes which enable userspace to change the brightness level,
> > > > which should also only be possible when vendor backlight control is
> > > > used.  Fast forward several years and on modern Fujitsu machines (e.g. 
> > > > Lifebook E744), the kernel automatically detects that native backlight 
> > > > control [1] should be used and SBLL becomes a noop [2].  This creates  
> > > > confusion, because the driver claims that it can get/set LCD brightness
> > > > level via the platform device's sysfs attributes, but it actually  
> > > > cannot.  It gets even more confusing on Skylake machines on which the  
> > > > FUJ02B1 ACPI device is not present at all. 
> 
> []
> 
> > > > The proposal I put forward in regard to the above is to remove the three
> > > > backlight-related attributes (brightness_changed, lcd_level,
> > > > max_brightness) from the platform driver's sysfs tree.  I believe the
> > > > functions they implement should only be exposed through the backlight
> > > > device, because the latter is only created when the user explicitly
> > > > selects vendor backlight control or it is automatically selected by the
> > > > kernel (this should be the case for older machines).
> > > 
> > > I will need to do some more digging into the historical developments.  At
> > > face value I'm not sure how machines like the S7020 would end up 
> > > controlling
> > > the backlight if these sysfs attributes were removed because on this 
> > > machine
> > > (at least last time I checked) the standard backlight/video drivers could
> > > not effect brightness control on this hardware.  Or is there a side effect
> > > that I have forgotten?
> > 
> > Let us not confuse three separate things that fujitsu-laptop enables:
> > 
> >   * changing LCD brightness using the keyboard,
> >   * changing LCD brightness from userspace, using the backlight device,
> >   * changing LCD brightness from userspace, using sysfs attributes.
> > 
> > I have nothing against the first two, apart from the notion that they
> > should be more tightly coupled (i.e. one should not be enabled without
> > the other one and vice versa).
> > 
> > I am all against the last one.  IMHO it is a duplicate, misplaced
> > feature which only makes clean separation of components inside the
> > driver hard.
> > 
> > > > That would leave us with the remaining three sysfs attributes of the
> > > > platform device, namely dock, lid and radios.  These all depend on the
> > > > FUJ02E3 ACPI device.  Which begs the question: shall we reassign them to
> > > > that ACPI device and drop the platform device altogether?  This would
> > > > logically be the correct thing to do (panasonic-laptop and toshiba_acpi
> > > > already assign extra sysfs attributes to ACPI nodes).  But I understand
> > > > that this would break an 8-year-old userspace interface as functions
> > > > previously exposed through /sys/devices/platform/fujitsu-laptop would be
> > > > moved to /sys/bus/acpi/devices/FUJ02E3:00.  If that is unacceptable, the
> > > > least we can (and should) do is to move platform device registration to
> > > > acpi_fujitsu_hotkey_add().  What the driver currently does may create
> > > > confusion in the future, because the platform device is registered
> > > > unconditionally while it clearly depends on FUJ02E3 being present.  I do
> > > > not know whether FUJ02E3 is present on all Fujitsu devices today without
> > > > exception, but I do know that if Fujitsu ever decides to drop that
> > > > device from its firmware, we would again (see above) expose a userspace
> > > > interface (dock, lid, radios) which simply will not be able to function
> > > > properly.
> 
> []
> 
> > > Regarding the movement of sysfs 

[PATCH v8 2/9] devicetree: property-units: Add uWh and uAh units

[Liam Breck]

From: Matt Ranostay 

Add entries for microwatt-hours and microamp-hours.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Ranostay 
Signed-off-by: Liam Breck 
Acked-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/property-units.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d7..0849618 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -25,8 +25,10 @@ Distance
 Electricity
 
 -microamp  : micro amps
+-microamp-hours : micro amp-hours
 -ohms  : Ohms
 -micro-ohms: micro Ohms
+-microwatt-hours: micro Watt-hours
 -microvolt : micro volts
 
 Temperature
-- 
2.9.3

[PATCH v8 2/9] devicetree: property-units: Add uWh and uAh units

[Liam Breck]

From: Matt Ranostay 

Add entries for microwatt-hours and microamp-hours.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Ranostay 
Signed-off-by: Liam Breck 
Acked-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/property-units.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d7..0849618 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -25,8 +25,10 @@ Distance
 Electricity
 
 -microamp  : micro amps
+-microamp-hours : micro amp-hours
 -ohms  : Ohms
 -micro-ohms: micro Ohms
+-microwatt-hours: micro Watt-hours
 -microvolt : micro volts
 
 Temperature
-- 
2.9.3

[GIT PULL] s390 patches for 4.11 merge window #2

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Next to the usual bug fixes (including the TASK_SIZE fix), there is
one larger crypto item. It allows to use protected keys with the
in-kernel crypto API. The protected key support has two parts,
the pkey user space API to convert key formats and the paes crypto
module that uses a protected key instead of a standard AES key.

Colin Ian King (1):
  s390/dasd: fix spelling mistake: "supportet" -> "supported"

Dominik Dingel (1):
  s390/mm: use _SEGMENT_ENTRY_EMPTY in the code

Harald Freudenberger (6):
  s390/zcrypt: Enable request count reset for cards and queues.
  s390/crypto: Add PCKMO inline function
  s390/zcrypt: Cleanup leftover module code.
  s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text.
  s390/zcrypt: export additional symbols
  s390/pkey: Introduce pkey kernel module

Heiko Carstens (5):
  s390: rename CIF_ASCE to CIF_ASCE_PRIMARY
  s390: restore address space when returning to user space
  s390: opt into HAVE_COPY_THREAD_TLS
  s390/nmi: fix order of register validation
  s390/nmi: purge tlbs after control register validation

Martin Schwidefsky (2):
  s390/crypt: Add protected key AES module
  s390: TASK_SIZE for kernel threads

Peter Oberparleiter (1):
  s390/chsc: Add exception handler for CHSC instruction

 arch/s390/Kconfig   |1 +
 arch/s390/configs/default_defconfig |1 +
 arch/s390/configs/performance_defconfig |1 +
 arch/s390/crypto/Makefile   |2 +-
 arch/s390/crypto/paes_s390.c|  619 +
 arch/s390/defconfig |1 +
 arch/s390/include/asm/cpacf.h   |   46 +-
 arch/s390/include/asm/mmu_context.h |4 +-
 arch/s390/include/asm/pgtable.h |   14 +-
 arch/s390/include/asm/pkey.h|   90 +++
 arch/s390/include/asm/processor.h   |   19 +-
 arch/s390/include/asm/uaccess.h |   23 +-
 arch/s390/include/uapi/asm/Kbuild   |1 +
 arch/s390/include/uapi/asm/pkey.h   |  112 +++
 arch/s390/kernel/entry.S|   33 +-
 arch/s390/kernel/entry.h|1 +
 arch/s390/kernel/nmi.c  |   25 +-
 arch/s390/kernel/process.c  |   18 +-
 arch/s390/mm/gmap.c |6 +-
 arch/s390/mm/hugetlbpage.c  |2 +-
 drivers/crypto/Kconfig  |   32 +-
 drivers/s390/block/dasd_eckd.c  |2 +-
 drivers/s390/cio/ioasm.c|8 +-
 drivers/s390/crypto/Makefile|4 +
 drivers/s390/crypto/ap_bus.c|   10 -
 drivers/s390/crypto/ap_card.c   |   24 +-
 drivers/s390/crypto/ap_queue.c  |   21 +-
 drivers/s390/crypto/pkey_api.c  | 1148 +++
 drivers/s390/crypto/zcrypt_api.c|5 +-
 drivers/s390/crypto/zcrypt_api.h|2 +
 30 files changed, 2182 insertions(+), 93 deletions(-)
 create mode 100644 arch/s390/crypto/paes_s390.c
 create mode 100644 arch/s390/include/asm/pkey.h
 create mode 100644 arch/s390/include/uapi/asm/pkey.h
 create mode 100644 drivers/s390/crypto/pkey_api.c

[GIT PULL] s390 patches for 4.11 merge window #2

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Next to the usual bug fixes (including the TASK_SIZE fix), there is
one larger crypto item. It allows to use protected keys with the
in-kernel crypto API. The protected key support has two parts,
the pkey user space API to convert key formats and the paes crypto
module that uses a protected key instead of a standard AES key.

Colin Ian King (1):
  s390/dasd: fix spelling mistake: "supportet" -> "supported"

Dominik Dingel (1):
  s390/mm: use _SEGMENT_ENTRY_EMPTY in the code

Harald Freudenberger (6):
  s390/zcrypt: Enable request count reset for cards and queues.
  s390/crypto: Add PCKMO inline function
  s390/zcrypt: Cleanup leftover module code.
  s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text.
  s390/zcrypt: export additional symbols
  s390/pkey: Introduce pkey kernel module

Heiko Carstens (5):
  s390: rename CIF_ASCE to CIF_ASCE_PRIMARY
  s390: restore address space when returning to user space
  s390: opt into HAVE_COPY_THREAD_TLS
  s390/nmi: fix order of register validation
  s390/nmi: purge tlbs after control register validation

Martin Schwidefsky (2):
  s390/crypt: Add protected key AES module
  s390: TASK_SIZE for kernel threads

Peter Oberparleiter (1):
  s390/chsc: Add exception handler for CHSC instruction

 arch/s390/Kconfig   |1 +
 arch/s390/configs/default_defconfig |1 +
 arch/s390/configs/performance_defconfig |1 +
 arch/s390/crypto/Makefile   |2 +-
 arch/s390/crypto/paes_s390.c|  619 +
 arch/s390/defconfig |1 +
 arch/s390/include/asm/cpacf.h   |   46 +-
 arch/s390/include/asm/mmu_context.h |4 +-
 arch/s390/include/asm/pgtable.h |   14 +-
 arch/s390/include/asm/pkey.h|   90 +++
 arch/s390/include/asm/processor.h   |   19 +-
 arch/s390/include/asm/uaccess.h |   23 +-
 arch/s390/include/uapi/asm/Kbuild   |1 +
 arch/s390/include/uapi/asm/pkey.h   |  112 +++
 arch/s390/kernel/entry.S|   33 +-
 arch/s390/kernel/entry.h|1 +
 arch/s390/kernel/nmi.c  |   25 +-
 arch/s390/kernel/process.c  |   18 +-
 arch/s390/mm/gmap.c |6 +-
 arch/s390/mm/hugetlbpage.c  |2 +-
 drivers/crypto/Kconfig  |   32 +-
 drivers/s390/block/dasd_eckd.c  |2 +-
 drivers/s390/cio/ioasm.c|8 +-
 drivers/s390/crypto/Makefile|4 +
 drivers/s390/crypto/ap_bus.c|   10 -
 drivers/s390/crypto/ap_card.c   |   24 +-
 drivers/s390/crypto/ap_queue.c  |   21 +-
 drivers/s390/crypto/pkey_api.c  | 1148 +++
 drivers/s390/crypto/zcrypt_api.c|5 +-
 drivers/s390/crypto/zcrypt_api.h|2 +
 30 files changed, 2182 insertions(+), 93 deletions(-)
 create mode 100644 arch/s390/crypto/paes_s390.c
 create mode 100644 arch/s390/include/asm/pkey.h
 create mode 100644 arch/s390/include/uapi/asm/pkey.h
 create mode 100644 drivers/s390/crypto/pkey_api.c

[PATCH] serial: sh-sci: Fix panic when serial console and DMA are enabled

[Yoshihiro Shimoda]

From: Takatoshi Akiyama 

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama 
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the following repo and tag:
  - renesas-drivers.git / renesas-drivers-2017-02-21-v4.10 tag

 drivers/tty/serial/sh-sci.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1d6f953..681e469 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1985,11 +1985,13 @@ static int sci_startup(struct uart_port *port)
 
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
 
+   sci_request_dma(port);
+
ret = sci_request_irq(s);
-   if (unlikely(ret < 0))
+   if (unlikely(ret < 0)) {
+   sci_free_dma(port);
return ret;
-
-   sci_request_dma(port);
+   }
 
return 0;
 }
@@ -2021,8 +2023,8 @@ static void sci_shutdown(struct uart_port *port)
}
 #endif
 
-   sci_free_dma(port);
sci_free_irq(s);
+   sci_free_dma(port);
 }
 
 static int sci_sck_calc(struct sci_port *s, unsigned int bps,
-- 
1.9.1

[PATCH] serial: sh-sci: Fix panic when serial console and DMA are enabled

[Yoshihiro Shimoda]

From: Takatoshi Akiyama 

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama 
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the following repo and tag:
  - renesas-drivers.git / renesas-drivers-2017-02-21-v4.10 tag

 drivers/tty/serial/sh-sci.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1d6f953..681e469 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1985,11 +1985,13 @@ static int sci_startup(struct uart_port *port)
 
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
 
+   sci_request_dma(port);
+
ret = sci_request_irq(s);
-   if (unlikely(ret < 0))
+   if (unlikely(ret < 0)) {
+   sci_free_dma(port);
return ret;
-
-   sci_request_dma(port);
+   }
 
return 0;
 }
@@ -2021,8 +2023,8 @@ static void sci_shutdown(struct uart_port *port)
}
 #endif
 
-   sci_free_dma(port);
sci_free_irq(s);
+   sci_free_dma(port);
 }
 
 static int sci_sck_calc(struct sci_port *s, unsigned int bps,
-- 
1.9.1

Re: [PATCH V5 3/6] mm: move MADV_FREE pages into LRU_INACTIVE_FILE list

[Minchan Kim]

Hello Shaohua,

On Fri, Feb 24, 2017 at 01:31:46PM -0800, Shaohua Li wrote:
> madv MADV_FREE indicate pages are 'lazyfree'. They are still anonymous
> pages, but they can be freed without pageout. To destinguish them
> against normal anonymous pages, we clear their SwapBacked flag.
> 
> MADV_FREE pages could be freed without pageout, so they pretty much like
> used once file pages. For such pages, we'd like to reclaim them once
> there is memory pressure. Also it might be unfair reclaiming MADV_FREE
> pages always before used once file pages and we definitively want to
> reclaim the pages before other anonymous and file pages.
> 
> To speed up MADV_FREE pages reclaim, we put the pages into
> LRU_INACTIVE_FILE list. The rationale is LRU_INACTIVE_FILE list is tiny
> nowadays and should be full of used once file pages. Reclaiming
> MADV_FREE pages will not have much interfere of anonymous and active
> file pages. And the inactive file pages and MADV_FREE pages will be
> reclaimed according to their age, so we don't reclaim too many MADV_FREE
> pages too. Putting the MADV_FREE pages into LRU_INACTIVE_FILE_LIST also
> means we can reclaim the pages without swap support. This idea is
> suggested by Johannes.
> 
> This patch doesn't move MADV_FREE pages to LRU_INACTIVE_FILE list yet to
> avoid bisect failure, next patch will do it.
> 
> The patch is based on Minchan's original patch.
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Suggested-by: Johannes Weiner 
> Signed-off-by: Shaohua Li 

This patch doesn't address I pointed out in v4.

https://marc.info/?i=20170224233752.GB4635%40bbox

Let's discuss it if you still are against.

Re: [PATCH V5 3/6] mm: move MADV_FREE pages into LRU_INACTIVE_FILE list

[Minchan Kim]

Hello Shaohua,

On Fri, Feb 24, 2017 at 01:31:46PM -0800, Shaohua Li wrote:
> madv MADV_FREE indicate pages are 'lazyfree'. They are still anonymous
> pages, but they can be freed without pageout. To destinguish them
> against normal anonymous pages, we clear their SwapBacked flag.
> 
> MADV_FREE pages could be freed without pageout, so they pretty much like
> used once file pages. For such pages, we'd like to reclaim them once
> there is memory pressure. Also it might be unfair reclaiming MADV_FREE
> pages always before used once file pages and we definitively want to
> reclaim the pages before other anonymous and file pages.
> 
> To speed up MADV_FREE pages reclaim, we put the pages into
> LRU_INACTIVE_FILE list. The rationale is LRU_INACTIVE_FILE list is tiny
> nowadays and should be full of used once file pages. Reclaiming
> MADV_FREE pages will not have much interfere of anonymous and active
> file pages. And the inactive file pages and MADV_FREE pages will be
> reclaimed according to their age, so we don't reclaim too many MADV_FREE
> pages too. Putting the MADV_FREE pages into LRU_INACTIVE_FILE_LIST also
> means we can reclaim the pages without swap support. This idea is
> suggested by Johannes.
> 
> This patch doesn't move MADV_FREE pages to LRU_INACTIVE_FILE list yet to
> avoid bisect failure, next patch will do it.
> 
> The patch is based on Minchan's original patch.
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Suggested-by: Johannes Weiner 
> Signed-off-by: Shaohua Li 

This patch doesn't address I pointed out in v4.

https://marc.info/?i=20170224233752.GB4635%40bbox

Let's discuss it if you still are against.

Re: [PATCH V5 2/6] mm: don't assume anonymous pages have SwapBacked flag

[Hillf Danton]

On February 25, 2017 5:32 AM Shaohua Li wrote: 
> 
> There are a few places the code assumes anonymous pages should have
> SwapBacked flag set. MADV_FREE pages are anonymous pages but we are
> going to add them to LRU_INACTIVE_FILE list and clear SwapBacked flag
> for them. The assumption doesn't hold any more, so fix them.
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Acked-by: Johannes Weiner 
> Signed-off-by: Shaohua Li 
> ---

Acked-by: Hillf Danton 

Re: [PATCH V5 2/6] mm: don't assume anonymous pages have SwapBacked flag

[Hillf Danton]

On February 25, 2017 5:32 AM Shaohua Li wrote: 
> 
> There are a few places the code assumes anonymous pages should have
> SwapBacked flag set. MADV_FREE pages are anonymous pages but we are
> going to add them to LRU_INACTIVE_FILE list and clear SwapBacked flag
> for them. The assumption doesn't hold any more, so fix them.
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Acked-by: Johannes Weiner 
> Signed-off-by: Shaohua Li 
> ---

Acked-by: Hillf Danton 

Re: [PATCH V5 4/6] mm: reclaim MADV_FREE pages

[Minchan Kim]

Hi Shaohua,

On Fri, Feb 24, 2017 at 01:31:47PM -0800, Shaohua Li wrote:
> When memory pressure is high, we free MADV_FREE pages. If the pages are
> not dirty in pte, the pages could be freed immediately. Otherwise we
> can't reclaim them. We put the pages back to anonumous LRU list (by
> setting SwapBacked flag) and the pages will be reclaimed in normal
> swapout way.
> 
> We use normal page reclaim policy. Since MADV_FREE pages are put into
> inactive file list, such pages and inactive file pages are reclaimed
> according to their age. This is expected, because we don't want to
> reclaim too many MADV_FREE pages before used once pages.
> 
> Based on Minchan's original patch
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Johannes Weiner 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Signed-off-by: Shaohua Li 
> ---
>  include/linux/rmap.h |  2 +-
>  mm/huge_memory.c |  2 ++
>  mm/madvise.c |  1 +
>  mm/rmap.c| 40 +---
>  mm/vmscan.c  | 34 ++
>  5 files changed, 43 insertions(+), 36 deletions(-)
> 
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 7a39414..fee10d7 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -298,6 +298,6 @@ static inline int page_mkclean(struct page *page)
>  #define SWAP_AGAIN   1
>  #define SWAP_FAIL2
>  #define SWAP_MLOCK   3
> -#define SWAP_LZFREE  4
> +#define SWAP_DIRTY   4

I still don't convinced why we should introduce SWAP_DIRTY in try_to_unmap.
https://marc.info/?l=linux-mm=148797879123238=2

We have been SetPageMlocked in there but why cannot we SetPageSwapBacked
in there? It's not a thing to change LRU type but it's just indication
we found the page's status changed in late.

>  
>  #endif   /* _LINUX_RMAP_H */
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 3b7ee0c..4c7454b 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1571,6 +1571,8 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, 
> struct vm_area_struct *vma,
>   set_pmd_at(mm, addr, pmd, orig_pmd);
>   tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
>   }
> +
> + mark_page_lazyfree(page);
>   ret = true;
>  out:
>   spin_unlock(ptl);
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 61e10b1..225af7d 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -413,6 +413,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   set_pte_at(mm, addr, pte, ptent);
>   tlb_remove_tlb_entry(tlb, pte, addr);
>   }
> + mark_page_lazyfree(page);
>   }
>  out:
>   if (nr_swap) {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index c621088..bb45712 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1281,11 +1281,6 @@ void page_remove_rmap(struct page *page, bool compound)
>*/
>  }
>  
> -struct rmap_private {
> - enum ttu_flags flags;
> - int lazyfreed;
> -};
> -
>  /*
>   * @arg: enum ttu_flags will be passed to this argument
>   */
> @@ -1301,8 +1296,7 @@ static int try_to_unmap_one(struct page *page, struct 
> vm_area_struct *vma,
>   pte_t pteval;
>   struct page *subpage;
>   int ret = SWAP_AGAIN;
> - struct rmap_private *rp = arg;
> - enum ttu_flags flags = rp->flags;
> + enum ttu_flags flags = (enum ttu_flags)arg;
>  
>   /* munlock has nothing to gain from examining un-locked vmas */
>   if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
> @@ -1419,11 +1413,21 @@ static int try_to_unmap_one(struct page *page, struct 
> vm_area_struct *vma,
>   VM_BUG_ON_PAGE(!PageSwapCache(page) && 
> PageSwapBacked(page),
>   page);
>  
> - if (!PageDirty(page)) {
> + /*
> +  * swapin page could be clean, it has data stored in
> +  * swap. We can't silently discard it without setting
> +  * swap entry in the page table.
> +  */
> + if (!PageDirty(page) && !PageSwapCache(page)) {
>   /* It's a freeable page by MADV_FREE */
>   dec_mm_counter(mm, MM_ANONPAGES);
> - rp->lazyfreed++;
>   goto discard;
> + } else if (!PageSwapBacked(page)) {
> + /* dirty MADV_FREE page */
> + set_pte_at(mm, address, pvmw.pte, pteval);
> + ret = SWAP_DIRTY;
> + page_vma_mapped_walk_done();
> + break;
>   }
>  
>   if 

Re: [PATCH V5 4/6] mm: reclaim MADV_FREE pages

[Minchan Kim]

Hi Shaohua,

On Fri, Feb 24, 2017 at 01:31:47PM -0800, Shaohua Li wrote:
> When memory pressure is high, we free MADV_FREE pages. If the pages are
> not dirty in pte, the pages could be freed immediately. Otherwise we
> can't reclaim them. We put the pages back to anonumous LRU list (by
> setting SwapBacked flag) and the pages will be reclaimed in normal
> swapout way.
> 
> We use normal page reclaim policy. Since MADV_FREE pages are put into
> inactive file list, such pages and inactive file pages are reclaimed
> according to their age. This is expected, because we don't want to
> reclaim too many MADV_FREE pages before used once pages.
> 
> Based on Minchan's original patch
> 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Johannes Weiner 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Andrew Morton 
> Signed-off-by: Shaohua Li 
> ---
>  include/linux/rmap.h |  2 +-
>  mm/huge_memory.c |  2 ++
>  mm/madvise.c |  1 +
>  mm/rmap.c| 40 +---
>  mm/vmscan.c  | 34 ++
>  5 files changed, 43 insertions(+), 36 deletions(-)
> 
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 7a39414..fee10d7 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -298,6 +298,6 @@ static inline int page_mkclean(struct page *page)
>  #define SWAP_AGAIN   1
>  #define SWAP_FAIL2
>  #define SWAP_MLOCK   3
> -#define SWAP_LZFREE  4
> +#define SWAP_DIRTY   4

I still don't convinced why we should introduce SWAP_DIRTY in try_to_unmap.
https://marc.info/?l=linux-mm=148797879123238=2

We have been SetPageMlocked in there but why cannot we SetPageSwapBacked
in there? It's not a thing to change LRU type but it's just indication
we found the page's status changed in late.

>  
>  #endif   /* _LINUX_RMAP_H */
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 3b7ee0c..4c7454b 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1571,6 +1571,8 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, 
> struct vm_area_struct *vma,
>   set_pmd_at(mm, addr, pmd, orig_pmd);
>   tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
>   }
> +
> + mark_page_lazyfree(page);
>   ret = true;
>  out:
>   spin_unlock(ptl);
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 61e10b1..225af7d 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -413,6 +413,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   set_pte_at(mm, addr, pte, ptent);
>   tlb_remove_tlb_entry(tlb, pte, addr);
>   }
> + mark_page_lazyfree(page);
>   }
>  out:
>   if (nr_swap) {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index c621088..bb45712 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1281,11 +1281,6 @@ void page_remove_rmap(struct page *page, bool compound)
>*/
>  }
>  
> -struct rmap_private {
> - enum ttu_flags flags;
> - int lazyfreed;
> -};
> -
>  /*
>   * @arg: enum ttu_flags will be passed to this argument
>   */
> @@ -1301,8 +1296,7 @@ static int try_to_unmap_one(struct page *page, struct 
> vm_area_struct *vma,
>   pte_t pteval;
>   struct page *subpage;
>   int ret = SWAP_AGAIN;
> - struct rmap_private *rp = arg;
> - enum ttu_flags flags = rp->flags;
> + enum ttu_flags flags = (enum ttu_flags)arg;
>  
>   /* munlock has nothing to gain from examining un-locked vmas */
>   if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
> @@ -1419,11 +1413,21 @@ static int try_to_unmap_one(struct page *page, struct 
> vm_area_struct *vma,
>   VM_BUG_ON_PAGE(!PageSwapCache(page) && 
> PageSwapBacked(page),
>   page);
>  
> - if (!PageDirty(page)) {
> + /*
> +  * swapin page could be clean, it has data stored in
> +  * swap. We can't silently discard it without setting
> +  * swap entry in the page table.
> +  */
> + if (!PageDirty(page) && !PageSwapCache(page)) {
>   /* It's a freeable page by MADV_FREE */
>   dec_mm_counter(mm, MM_ANONPAGES);
> - rp->lazyfreed++;
>   goto discard;
> + } else if (!PageSwapBacked(page)) {
> + /* dirty MADV_FREE page */
> + set_pte_at(mm, address, pvmw.pte, pteval);
> + ret = SWAP_DIRTY;
> + page_vma_mapped_walk_done();
> + break;
>   }
>  
>   if (swap_duplicate(entry) < 0) {
> @@ -1491,18 +1495,15 @@ static int page_mapcount_is_zero(struct page *page)
>   * SWAP_AGAIN- we missed a mapping, try again later
>   * 

Re: [Outreachy kernel] [PATCH] staging: bcm2835-audio: Fixed spacing around '&'

[Julia Lawall]

On Sun, 26 Feb 2017, Scott Branden wrote:

>
>
> On 17-02-26 01:56 PM, Joe Perches wrote:
> > On Sun, 2017-02-26 at 20:40 +0100, Julia Lawall wrote:
> > > On Sun, 26 Feb 2017, Joe Perches wrote:
> > > > On Sun, 2017-02-26 at 19:59 +0100, Julia Lawall wrote:
> > > > > On Sun, 26 Feb 2017, Joe Perches wrot
> > > > > > Mailing lists _should_ be copied on patch submissions.
> > > > > The idea of outreachy is that it should be a place for people to get
> > > > > started without too much criticism from the outside.  Originally, only
> > > > > the
> > > > > outreachy mailing list received patches.  But staging maintainers were
> > > > > confused to have their drivers receiving patches that they had not
> > > > > seen.
> > > > > So we expanded it to maintainers.
> > > >
> > > > That also doesn't make much sense as patches
> > > > should not be applied that have not reached
> > > > a mailing list for review.
> > > >
> > > > As long as initial outreachy patches are not
> > > > applied and are just for internal review by
> > > > any outside person but the outreachy list and
> > > > are not be applied by maintainers, then perhaps
> > > > it's best if neither maintainers nor lists are
> > > > cc'd on the patches.
> > >
> > > The patches are applied by Greg.  Greg suggested the policy of adding
> > > maintainers but not including mailing lists.  I'll let him consider
> > > whether the policy should be changed.
> >
> > Well, I will comment on patches sent to the kernel list.
> >
> > I'm not subscribed to outreachy and I don't want to be
> > subscribed to that list either.
> >
> I would prefer this outreachy work uses their own mailing list and reviews
> their patches first.  Then once they have everything sorted out they send out
> the patch series to the proper maintainers/mailing lists. That way we're not
> spammed with all these emails of people as they are learning how to format and
> send out proper patches.

If you consider that you are getting too much outreachy mail at the
moment, just let me know what subsystem you want me to add an exception
for.

thanks,
julia

Re: [Outreachy kernel] [PATCH] staging: bcm2835-audio: Fixed spacing around '&'

[Julia Lawall]

On Sun, 26 Feb 2017, Scott Branden wrote:

>
>
> On 17-02-26 01:56 PM, Joe Perches wrote:
> > On Sun, 2017-02-26 at 20:40 +0100, Julia Lawall wrote:
> > > On Sun, 26 Feb 2017, Joe Perches wrote:
> > > > On Sun, 2017-02-26 at 19:59 +0100, Julia Lawall wrote:
> > > > > On Sun, 26 Feb 2017, Joe Perches wrot
> > > > > > Mailing lists _should_ be copied on patch submissions.
> > > > > The idea of outreachy is that it should be a place for people to get
> > > > > started without too much criticism from the outside.  Originally, only
> > > > > the
> > > > > outreachy mailing list received patches.  But staging maintainers were
> > > > > confused to have their drivers receiving patches that they had not
> > > > > seen.
> > > > > So we expanded it to maintainers.
> > > >
> > > > That also doesn't make much sense as patches
> > > > should not be applied that have not reached
> > > > a mailing list for review.
> > > >
> > > > As long as initial outreachy patches are not
> > > > applied and are just for internal review by
> > > > any outside person but the outreachy list and
> > > > are not be applied by maintainers, then perhaps
> > > > it's best if neither maintainers nor lists are
> > > > cc'd on the patches.
> > >
> > > The patches are applied by Greg.  Greg suggested the policy of adding
> > > maintainers but not including mailing lists.  I'll let him consider
> > > whether the policy should be changed.
> >
> > Well, I will comment on patches sent to the kernel list.
> >
> > I'm not subscribed to outreachy and I don't want to be
> > subscribed to that list either.
> >
> I would prefer this outreachy work uses their own mailing list and reviews
> their patches first.  Then once they have everything sorted out they send out
> the patch series to the proper maintainers/mailing lists. That way we're not
> spammed with all these emails of people as they are learning how to format and
> send out proper patches.

If you consider that you are getting too much outreachy mail at the
moment, just let me know what subsystem you want me to add an exception
for.

thanks,
julia

Re: [PATCH 1/3] mm, vmscan: fix zone balance check in prepare_kswapd_sleep

[Minchan Kim]

Hi Mel,

On Fri, Feb 24, 2017 at 09:11:28AM +, Mel Gorman wrote:
> On Fri, Feb 24, 2017 at 10:17:06AM +0900, Minchan Kim wrote:
> > Hi Mel,
> > 
> > On Thu, Feb 23, 2017 at 03:05:34PM +, Mel Gorman wrote:
> > > On Wed, Feb 22, 2017 at 04:00:36PM +0900, Minchan Kim wrote:
> > > > > There are also more allocation stalls. One of the largest impacts was 
> > > > > due
> > > > > to pages written back from kswapd context rising from 0 pages to 
> > > > > 4516642
> > > > > pages during the hour the workload ran for. By and large, the patch 
> > > > > has very
> > > > > bad behaviour but easily missed as the impact on a UMA machine is 
> > > > > negligible.
> > > > > 
> > > > > This patch is included with the data in case a bisection leads to 
> > > > > this area.
> > > > > This patch is also a pre-requisite for the rest of the series.
> > > > > 
> > > > > Signed-off-by: Shantanu Goel 
> > > > > Signed-off-by: Mel Gorman 
> > > > 
> > > > Hmm, I don't understand why we should bind wakeup_kcompactd to kswapd's
> > > > short sleep point where every eligible zones are balanced.
> > > > What's the correlation between them?
> > > > 
> > > 
> > > If kswapd is ready for a short sleep, eligible zones are balanced for
> > > order-0 but not necessarily the originally requested order if kswapd
> > > gave up reclaiming as compaction was ready to start. As kswapd is ready
> > > to sleep for a short period, it's a suitable time for kcompactd to decide
> > > if it should start working or not. There is no need for kswapd to be aware
> > > of kcompactd's wakeup criteria.
> > 
> > If all eligible zones are balanced for order-0, I agree it's good timing
> > because high-order alloc's ratio would be higher since kcompactd can compact
> > eligible zones, not that only classzone.
> > However, this patch breaks it as well as long time kswapd behavior which
> > continues to balance eligible zones for order-0.
> > Is it really okay now?
> > 
> 
> Reclaim stops in balance_pgdat() if any eligible zone for the requested
> classzone is free. The initial sleep for kswapd is very different because
> it'll sleep if all zones are balanced for order-0 which is a bad disconnect.
> The way node balancing works means there is no guarantee at all that all
> zones will be balanced even if there is little or no memory pressure and
> one large zone in a node with multiple zones can be balanced quickly.

Indeed but it would tip toward direct relcaim more so it could make more
failure for allocation relies on kswapd like atomic allocation
However, if VM balance all of zones for order-0, it would make excessive
reclaim with node-based LRU unlike zone-based, which is bad, too.

> 
> The short-sleep logic that kswapd uses to decide whether to go to sleep
> is shortcut and it does not properly try the short sleep checking if the
> high watermarks are quickly reached or not. Instead, it quickly fails the
> first attempt at sleep, reenters balance_pgdat(), finds nothing to do and
> rechecks sleeping based on order-0, classzone-0 which it can easily sleep
> for but is *not* what kswapd was woken for in the first place.
> 
> For many allocation requests that initially woke kswapd, the impact is
> marginal. kswapd sleeps early and is woken in the near future if there
> is a continual stream of allocations with a risk that direct reclaim is
> required. While the motivation for the patch was that kcompact is not woken
> up, the existing behaviour is just wrong -- kswapd should be deciding to
> sleep based on the classzone it was woken for and if possible, the order
> it was woken for but the classzone is more important in the common case
> for order-0 allocations.

I agree but I think it's rather risky to paper over order-0 zone-balancing
problem by kcompactd missing problem so at least, it should be documented.

Thanks.

Re: [PATCH 1/3] mm, vmscan: fix zone balance check in prepare_kswapd_sleep

[Minchan Kim]

Hi Mel,

On Fri, Feb 24, 2017 at 09:11:28AM +, Mel Gorman wrote:
> On Fri, Feb 24, 2017 at 10:17:06AM +0900, Minchan Kim wrote:
> > Hi Mel,
> > 
> > On Thu, Feb 23, 2017 at 03:05:34PM +, Mel Gorman wrote:
> > > On Wed, Feb 22, 2017 at 04:00:36PM +0900, Minchan Kim wrote:
> > > > > There are also more allocation stalls. One of the largest impacts was 
> > > > > due
> > > > > to pages written back from kswapd context rising from 0 pages to 
> > > > > 4516642
> > > > > pages during the hour the workload ran for. By and large, the patch 
> > > > > has very
> > > > > bad behaviour but easily missed as the impact on a UMA machine is 
> > > > > negligible.
> > > > > 
> > > > > This patch is included with the data in case a bisection leads to 
> > > > > this area.
> > > > > This patch is also a pre-requisite for the rest of the series.
> > > > > 
> > > > > Signed-off-by: Shantanu Goel 
> > > > > Signed-off-by: Mel Gorman 
> > > > 
> > > > Hmm, I don't understand why we should bind wakeup_kcompactd to kswapd's
> > > > short sleep point where every eligible zones are balanced.
> > > > What's the correlation between them?
> > > > 
> > > 
> > > If kswapd is ready for a short sleep, eligible zones are balanced for
> > > order-0 but not necessarily the originally requested order if kswapd
> > > gave up reclaiming as compaction was ready to start. As kswapd is ready
> > > to sleep for a short period, it's a suitable time for kcompactd to decide
> > > if it should start working or not. There is no need for kswapd to be aware
> > > of kcompactd's wakeup criteria.
> > 
> > If all eligible zones are balanced for order-0, I agree it's good timing
> > because high-order alloc's ratio would be higher since kcompactd can compact
> > eligible zones, not that only classzone.
> > However, this patch breaks it as well as long time kswapd behavior which
> > continues to balance eligible zones for order-0.
> > Is it really okay now?
> > 
> 
> Reclaim stops in balance_pgdat() if any eligible zone for the requested
> classzone is free. The initial sleep for kswapd is very different because
> it'll sleep if all zones are balanced for order-0 which is a bad disconnect.
> The way node balancing works means there is no guarantee at all that all
> zones will be balanced even if there is little or no memory pressure and
> one large zone in a node with multiple zones can be balanced quickly.

Indeed but it would tip toward direct relcaim more so it could make more
failure for allocation relies on kswapd like atomic allocation
However, if VM balance all of zones for order-0, it would make excessive
reclaim with node-based LRU unlike zone-based, which is bad, too.

> 
> The short-sleep logic that kswapd uses to decide whether to go to sleep
> is shortcut and it does not properly try the short sleep checking if the
> high watermarks are quickly reached or not. Instead, it quickly fails the
> first attempt at sleep, reenters balance_pgdat(), finds nothing to do and
> rechecks sleeping based on order-0, classzone-0 which it can easily sleep
> for but is *not* what kswapd was woken for in the first place.
> 
> For many allocation requests that initially woke kswapd, the impact is
> marginal. kswapd sleeps early and is woken in the near future if there
> is a continual stream of allocations with a risk that direct reclaim is
> required. While the motivation for the patch was that kcompact is not woken
> up, the existing behaviour is just wrong -- kswapd should be deciding to
> sleep based on the classzone it was woken for and if possible, the order
> it was woken for but the classzone is more important in the common case
> for order-0 allocations.

I agree but I think it's rather risky to paper over order-0 zone-balancing
problem by kcompactd missing problem so at least, it should be documented.

Thanks.

Re: [PATCH v2] mm/vmscan: fix high cpu usage of kswapd if there are no reclaimable pages

[hejianet]

Hi
Tested-by: Jia He 

cat /proc/meminfo
[...]
CmaFree:   0 kB
HugePages_Total:1831
HugePages_Free: 1831
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:  16384 kB

top - 06:50:29 up  1:26,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.6 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  31371520 total, 30577664 used,   793856 free,  256 buffers
KiB Swap:  6284224 total,  128 used,  6284096 free.   281280 cached Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
   79 root  20   0   0  0  0 S 0.000 0.000   0:00.00 kswapd3


On 25/02/2017 12:51 AM, Johannes Weiner wrote:

On Fri, Feb 24, 2017 at 09:49:50AM +0100, Michal Hocko wrote:

I believe we should pursue the proposal from Johannes which is more
generic and copes with corner cases much better.


Jia, can you try this? I'll put the cleanups in follow-up patches.

---


From 29fefdca148e28830e0934d4e6cceb95ed2ee36e Mon Sep 17 00:00:00 2001

From: Johannes Weiner 
Date: Fri, 24 Feb 2017 10:56:32 -0500
Subject: [PATCH] mm: vmscan: disable kswapd on unreclaimable nodes

Jia He reports a problem with kswapd spinning at 100% CPU when
requesting more hugepages than memory available in the system:

$ echo 4000 >/proc/sys/vm/nr_hugepages

top - 13:42:59 up  3:37,  1 user,  load average: 1.09, 1.03, 1.01
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 12.5 sy,  0.0 ni, 85.5 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  31371520 total, 30915136 used,   456384 free,  320 buffers
KiB Swap:  6284224 total,   115712 used,  6168512 free.48192 cached Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
   76 root  20   0   0  0  0 R 100.0 0.000 217:17.29 kswapd3

At that time, there are no reclaimable pages left in the node, but as
kswapd fails to restore the high watermarks it refuses to go to sleep.

Kswapd needs to back away from nodes that fail to balance. Up until
1d82de618ddd ("mm, vmscan: make kswapd reclaim in terms of nodes")
kswapd had such a mechanism. It considered zones whose theoretically
reclaimable pages it had reclaimed six times over as unreclaimable and
backed away from them. This guard was erroneously removed as the patch
changed the definition of a balanced node.

However, simply restoring this code wouldn't help in the case reported
here: there *are* no reclaimable pages that could be scanned until the
threshold is met. Kswapd would stay awake anyway.

Introduce a new and much simpler way of backing off. If kswapd runs
through MAX_RECLAIM_RETRIES (16) cycles without reclaiming a single
page, make it back off from the node. This is the same number of shots
direct reclaim takes before declaring OOM. Kswapd will go to sleep on
that node until a direct reclaimer manages to reclaim some pages, thus
proving the node reclaimable again.

Reported-by: Jia He 
Signed-off-by: Johannes Weiner 
---
 include/linux/mmzone.h |  2 ++
 include/linux/swap.h   |  1 +
 mm/page_alloc.c|  6 --
 mm/vmscan.c| 20 
 4 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 8e02b3750fe0..d2c50ab6ae40 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -630,6 +630,8 @@ typedef struct pglist_data {
int kswapd_order;
enum zone_type kswapd_classzone_idx;

+   int kswapd_failures;/* Number of 'reclaimed == 0' runs */
+
 #ifdef CONFIG_COMPACTION
int kcompactd_max_order;
enum zone_type kcompactd_classzone_idx;
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 45e91dd6716d..5c06581a730b 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -288,6 +288,7 @@ extern void lru_cache_add_active_or_unevictable(struct page 
*page,
struct vm_area_struct *vma);

 /* linux/mm/vmscan.c */
+#define MAX_RECLAIM_RETRIES 16
 extern unsigned long zone_reclaimable_pages(struct zone *zone);
 extern unsigned long pgdat_reclaimable_pages(struct pglist_data *pgdat);
 extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 614cd0397ce3..83f0442f07fa 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3516,12 +3516,6 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
 }

 /*
- * Maximum number of reclaim retries without any progress before OOM killer
- * is consider as the only way to move forward.
- */
-#define MAX_RECLAIM_RETRIES 16
-
-/*
  * Checks whether it makes sense to retry the reclaim to make a forward 
progress
  * for the given allocation request.
  * The reclaim feedback represented by did_some_progress (any progress 

Re: [PATCH v2] mm/vmscan: fix high cpu usage of kswapd if there are no reclaimable pages

[hejianet]

Hi
Tested-by: Jia He 

cat /proc/meminfo
[...]
CmaFree:   0 kB
HugePages_Total:1831
HugePages_Free: 1831
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:  16384 kB

top - 06:50:29 up  1:26,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.6 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  31371520 total, 30577664 used,   793856 free,  256 buffers
KiB Swap:  6284224 total,  128 used,  6284096 free.   281280 cached Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
   79 root  20   0   0  0  0 S 0.000 0.000   0:00.00 kswapd3


On 25/02/2017 12:51 AM, Johannes Weiner wrote:

On Fri, Feb 24, 2017 at 09:49:50AM +0100, Michal Hocko wrote:

I believe we should pursue the proposal from Johannes which is more
generic and copes with corner cases much better.


Jia, can you try this? I'll put the cleanups in follow-up patches.

---


From 29fefdca148e28830e0934d4e6cceb95ed2ee36e Mon Sep 17 00:00:00 2001

From: Johannes Weiner 
Date: Fri, 24 Feb 2017 10:56:32 -0500
Subject: [PATCH] mm: vmscan: disable kswapd on unreclaimable nodes

Jia He reports a problem with kswapd spinning at 100% CPU when
requesting more hugepages than memory available in the system:

$ echo 4000 >/proc/sys/vm/nr_hugepages

top - 13:42:59 up  3:37,  1 user,  load average: 1.09, 1.03, 1.01
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 12.5 sy,  0.0 ni, 85.5 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  31371520 total, 30915136 used,   456384 free,  320 buffers
KiB Swap:  6284224 total,   115712 used,  6168512 free.48192 cached Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
   76 root  20   0   0  0  0 R 100.0 0.000 217:17.29 kswapd3

At that time, there are no reclaimable pages left in the node, but as
kswapd fails to restore the high watermarks it refuses to go to sleep.

Kswapd needs to back away from nodes that fail to balance. Up until
1d82de618ddd ("mm, vmscan: make kswapd reclaim in terms of nodes")
kswapd had such a mechanism. It considered zones whose theoretically
reclaimable pages it had reclaimed six times over as unreclaimable and
backed away from them. This guard was erroneously removed as the patch
changed the definition of a balanced node.

However, simply restoring this code wouldn't help in the case reported
here: there *are* no reclaimable pages that could be scanned until the
threshold is met. Kswapd would stay awake anyway.

Introduce a new and much simpler way of backing off. If kswapd runs
through MAX_RECLAIM_RETRIES (16) cycles without reclaiming a single
page, make it back off from the node. This is the same number of shots
direct reclaim takes before declaring OOM. Kswapd will go to sleep on
that node until a direct reclaimer manages to reclaim some pages, thus
proving the node reclaimable again.

Reported-by: Jia He 
Signed-off-by: Johannes Weiner 
---
 include/linux/mmzone.h |  2 ++
 include/linux/swap.h   |  1 +
 mm/page_alloc.c|  6 --
 mm/vmscan.c| 20 
 4 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 8e02b3750fe0..d2c50ab6ae40 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -630,6 +630,8 @@ typedef struct pglist_data {
int kswapd_order;
enum zone_type kswapd_classzone_idx;

+   int kswapd_failures;/* Number of 'reclaimed == 0' runs */
+
 #ifdef CONFIG_COMPACTION
int kcompactd_max_order;
enum zone_type kcompactd_classzone_idx;
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 45e91dd6716d..5c06581a730b 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -288,6 +288,7 @@ extern void lru_cache_add_active_or_unevictable(struct page 
*page,
struct vm_area_struct *vma);

 /* linux/mm/vmscan.c */
+#define MAX_RECLAIM_RETRIES 16
 extern unsigned long zone_reclaimable_pages(struct zone *zone);
 extern unsigned long pgdat_reclaimable_pages(struct pglist_data *pgdat);
 extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 614cd0397ce3..83f0442f07fa 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3516,12 +3516,6 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
 }

 /*
- * Maximum number of reclaim retries without any progress before OOM killer
- * is consider as the only way to move forward.
- */
-#define MAX_RECLAIM_RETRIES 16
-
-/*
  * Checks whether it makes sense to retry the reclaim to make a forward 
progress
  * for the given allocation request.
  * The reclaim feedback represented by did_some_progress (any progress during
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 26c3b405ef34..8e9bdd172182 100644

Re: [PATCHv3 1/4] Encasing macros with complex values (ie: base value plus index) with parentheses.

[Tobin C. Harding]

On Sun, Feb 26, 2017 at 06:00:19PM -0800, Matthew Giassa wrote:
> ---
>  drivers/staging/ks7010/ks_wlan_ioctl.h | 64 
> +-
>  1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
> b/drivers/staging/ks7010/ks_wlan_ioctl.h
> index 8e62b10..47c8015 100644
> --- a/drivers/staging/ks7010/ks_wlan_ioctl.h
> +++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
> @@ -15,43 +15,43 @@
>  #include 
>  /* The low order bit identify a SET (0) or a GET (1) ioctl.  */


Patches without a git log won't be able to be merged. Please see
Documentation/process/submitting-patches.rst

thanks,
Tobin.

>  
> -/*   SIOCIWFIRSTPRIV + 0 */
> -/* former KS_WLAN_GET_DRIVER_VERSION SIOCIWFIRSTPRIV + 1 */
> -/*   SIOCIWFIRSTPRIV + 2 */
> -#define KS_WLAN_GET_FIRM_VERSION SIOCIWFIRSTPRIV + 3
> +/*   (SIOCIWFIRSTPRIV + 0) */
> +/* former KS_WLAN_GET_DRIVER_VERSION (SIOCIWFIRSTPRIV + 1) */
> +/*   (SIOCIWFIRSTPRIV + 2) */
> +#define KS_WLAN_GET_FIRM_VERSION (SIOCIWFIRSTPRIV + 3)
>  #ifdef WPS
> -#define KS_WLAN_SET_WPS_ENABLE   SIOCIWFIRSTPRIV + 4
> -#define KS_WLAN_GET_WPS_ENABLE   SIOCIWFIRSTPRIV + 5
> -#define KS_WLAN_SET_WPS_PROBE_REQSIOCIWFIRSTPRIV + 6
> +#define KS_WLAN_SET_WPS_ENABLE   (SIOCIWFIRSTPRIV + 4)
> +#define KS_WLAN_GET_WPS_ENABLE   (SIOCIWFIRSTPRIV + 5)
> +#define KS_WLAN_SET_WPS_PROBE_REQ(SIOCIWFIRSTPRIV + 6)
>  #endif
> -#define KS_WLAN_GET_EEPROM_CKSUM SIOCIWFIRSTPRIV + 7
> -#define KS_WLAN_SET_PREAMBLE SIOCIWFIRSTPRIV + 8
> -#define KS_WLAN_GET_PREAMBLE SIOCIWFIRSTPRIV + 9
> -#define KS_WLAN_SET_POWER_SAVE   SIOCIWFIRSTPRIV + 10
> -#define KS_WLAN_GET_POWER_SAVE   SIOCIWFIRSTPRIV + 11
> -#define KS_WLAN_SET_SCAN_TYPESIOCIWFIRSTPRIV + 12
> -#define KS_WLAN_GET_SCAN_TYPESIOCIWFIRSTPRIV + 13
> -#define KS_WLAN_SET_RX_GAIN  SIOCIWFIRSTPRIV + 14
> -#define KS_WLAN_GET_RX_GAIN  SIOCIWFIRSTPRIV + 15
> -#define KS_WLAN_HOSTTSIOCIWFIRSTPRIV + 16/* 
> unused */
> -//#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV + 17
> -#define KS_WLAN_SET_BEACON_LOST  SIOCIWFIRSTPRIV + 18
> -#define KS_WLAN_GET_BEACON_LOST  SIOCIWFIRSTPRIV + 19
> +#define KS_WLAN_GET_EEPROM_CKSUM (SIOCIWFIRSTPRIV + 7)
> +#define KS_WLAN_SET_PREAMBLE (SIOCIWFIRSTPRIV + 8)
> +#define KS_WLAN_GET_PREAMBLE (SIOCIWFIRSTPRIV + 9)
> +#define KS_WLAN_SET_POWER_SAVE   (SIOCIWFIRSTPRIV + 10)
> +#define KS_WLAN_GET_POWER_SAVE   (SIOCIWFIRSTPRIV + 11)
> +#define KS_WLAN_SET_SCAN_TYPE(SIOCIWFIRSTPRIV + 12)
> +#define KS_WLAN_GET_SCAN_TYPE(SIOCIWFIRSTPRIV + 13)
> +#define KS_WLAN_SET_RX_GAIN  (SIOCIWFIRSTPRIV + 14)
> +#define KS_WLAN_GET_RX_GAIN  (SIOCIWFIRSTPRIV + 15)
> +#define KS_WLAN_HOSTT(SIOCIWFIRSTPRIV + 16) /* 
> unused */
> +//#define KS_WLAN_SET_REGION(SIOCIWFIRSTPRIV + 17)
> +#define KS_WLAN_SET_BEACON_LOST  (SIOCIWFIRSTPRIV + 18)
> +#define KS_WLAN_GET_BEACON_LOST  (SIOCIWFIRSTPRIV + 19)
>  
> -#define KS_WLAN_SET_TX_GAIN  SIOCIWFIRSTPRIV + 20
> -#define KS_WLAN_GET_TX_GAIN  SIOCIWFIRSTPRIV + 21
> +#define KS_WLAN_SET_TX_GAIN  (SIOCIWFIRSTPRIV + 20)
> +#define KS_WLAN_GET_TX_GAIN  (SIOCIWFIRSTPRIV + 21)
>  
>  /* for KS7010 */
> -#define KS_WLAN_SET_PHY_TYPE SIOCIWFIRSTPRIV + 22
> -#define KS_WLAN_GET_PHY_TYPE SIOCIWFIRSTPRIV + 23
> -#define KS_WLAN_SET_CTS_MODE SIOCIWFIRSTPRIV + 24
> -#define KS_WLAN_GET_CTS_MODE SIOCIWFIRSTPRIV + 25
> -/*   SIOCIWFIRSTPRIV + 26 */
> -/*   SIOCIWFIRSTPRIV + 27 */
> -#define KS_WLAN_SET_SLEEP_MODE   SIOCIWFIRSTPRIV + 28/* 
> sleep mode */
> -#define KS_WLAN_GET_SLEEP_MODE   SIOCIWFIRSTPRIV + 29/* 
> sleep mode */
> -/*   SIOCIWFIRSTPRIV + 30 */
> -/*   SIOCIWFIRSTPRIV + 31 */
> +#define KS_WLAN_SET_PHY_TYPE (SIOCIWFIRSTPRIV + 22)
> +#define KS_WLAN_GET_PHY_TYPE (SIOCIWFIRSTPRIV + 23)
> +#define KS_WLAN_SET_CTS_MODE (SIOCIWFIRSTPRIV + 24)
> +#define KS_WLAN_GET_CTS_MODE (SIOCIWFIRSTPRIV + 25)
> +/*   (SIOCIWFIRSTPRIV + 26) */
> +/*   (SIOCIWFIRSTPRIV + 27) */
> +#define KS_WLAN_SET_SLEEP_MODE   (SIOCIWFIRSTPRIV + 28) /* sleep 
> mode */
> +#define KS_WLAN_GET_SLEEP_MODE   (SIOCIWFIRSTPRIV + 29) /* sleep 
> mode */
> +/*   (SIOCIWFIRSTPRIV + 30) */
> +/*   

Re: [PATCHv3 1/4] Encasing macros with complex values (ie: base value plus index) with parentheses.

[Tobin C. Harding]

On Sun, Feb 26, 2017 at 06:00:19PM -0800, Matthew Giassa wrote:
> ---
>  drivers/staging/ks7010/ks_wlan_ioctl.h | 64 
> +-
>  1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
> b/drivers/staging/ks7010/ks_wlan_ioctl.h
> index 8e62b10..47c8015 100644
> --- a/drivers/staging/ks7010/ks_wlan_ioctl.h
> +++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
> @@ -15,43 +15,43 @@
>  #include 
>  /* The low order bit identify a SET (0) or a GET (1) ioctl.  */


Patches without a git log won't be able to be merged. Please see
Documentation/process/submitting-patches.rst

thanks,
Tobin.

>  
> -/*   SIOCIWFIRSTPRIV + 0 */
> -/* former KS_WLAN_GET_DRIVER_VERSION SIOCIWFIRSTPRIV + 1 */
> -/*   SIOCIWFIRSTPRIV + 2 */
> -#define KS_WLAN_GET_FIRM_VERSION SIOCIWFIRSTPRIV + 3
> +/*   (SIOCIWFIRSTPRIV + 0) */
> +/* former KS_WLAN_GET_DRIVER_VERSION (SIOCIWFIRSTPRIV + 1) */
> +/*   (SIOCIWFIRSTPRIV + 2) */
> +#define KS_WLAN_GET_FIRM_VERSION (SIOCIWFIRSTPRIV + 3)
>  #ifdef WPS
> -#define KS_WLAN_SET_WPS_ENABLE   SIOCIWFIRSTPRIV + 4
> -#define KS_WLAN_GET_WPS_ENABLE   SIOCIWFIRSTPRIV + 5
> -#define KS_WLAN_SET_WPS_PROBE_REQSIOCIWFIRSTPRIV + 6
> +#define KS_WLAN_SET_WPS_ENABLE   (SIOCIWFIRSTPRIV + 4)
> +#define KS_WLAN_GET_WPS_ENABLE   (SIOCIWFIRSTPRIV + 5)
> +#define KS_WLAN_SET_WPS_PROBE_REQ(SIOCIWFIRSTPRIV + 6)
>  #endif
> -#define KS_WLAN_GET_EEPROM_CKSUM SIOCIWFIRSTPRIV + 7
> -#define KS_WLAN_SET_PREAMBLE SIOCIWFIRSTPRIV + 8
> -#define KS_WLAN_GET_PREAMBLE SIOCIWFIRSTPRIV + 9
> -#define KS_WLAN_SET_POWER_SAVE   SIOCIWFIRSTPRIV + 10
> -#define KS_WLAN_GET_POWER_SAVE   SIOCIWFIRSTPRIV + 11
> -#define KS_WLAN_SET_SCAN_TYPESIOCIWFIRSTPRIV + 12
> -#define KS_WLAN_GET_SCAN_TYPESIOCIWFIRSTPRIV + 13
> -#define KS_WLAN_SET_RX_GAIN  SIOCIWFIRSTPRIV + 14
> -#define KS_WLAN_GET_RX_GAIN  SIOCIWFIRSTPRIV + 15
> -#define KS_WLAN_HOSTTSIOCIWFIRSTPRIV + 16/* 
> unused */
> -//#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV + 17
> -#define KS_WLAN_SET_BEACON_LOST  SIOCIWFIRSTPRIV + 18
> -#define KS_WLAN_GET_BEACON_LOST  SIOCIWFIRSTPRIV + 19
> +#define KS_WLAN_GET_EEPROM_CKSUM (SIOCIWFIRSTPRIV + 7)
> +#define KS_WLAN_SET_PREAMBLE (SIOCIWFIRSTPRIV + 8)
> +#define KS_WLAN_GET_PREAMBLE (SIOCIWFIRSTPRIV + 9)
> +#define KS_WLAN_SET_POWER_SAVE   (SIOCIWFIRSTPRIV + 10)
> +#define KS_WLAN_GET_POWER_SAVE   (SIOCIWFIRSTPRIV + 11)
> +#define KS_WLAN_SET_SCAN_TYPE(SIOCIWFIRSTPRIV + 12)
> +#define KS_WLAN_GET_SCAN_TYPE(SIOCIWFIRSTPRIV + 13)
> +#define KS_WLAN_SET_RX_GAIN  (SIOCIWFIRSTPRIV + 14)
> +#define KS_WLAN_GET_RX_GAIN  (SIOCIWFIRSTPRIV + 15)
> +#define KS_WLAN_HOSTT(SIOCIWFIRSTPRIV + 16) /* 
> unused */
> +//#define KS_WLAN_SET_REGION(SIOCIWFIRSTPRIV + 17)
> +#define KS_WLAN_SET_BEACON_LOST  (SIOCIWFIRSTPRIV + 18)
> +#define KS_WLAN_GET_BEACON_LOST  (SIOCIWFIRSTPRIV + 19)
>  
> -#define KS_WLAN_SET_TX_GAIN  SIOCIWFIRSTPRIV + 20
> -#define KS_WLAN_GET_TX_GAIN  SIOCIWFIRSTPRIV + 21
> +#define KS_WLAN_SET_TX_GAIN  (SIOCIWFIRSTPRIV + 20)
> +#define KS_WLAN_GET_TX_GAIN  (SIOCIWFIRSTPRIV + 21)
>  
>  /* for KS7010 */
> -#define KS_WLAN_SET_PHY_TYPE SIOCIWFIRSTPRIV + 22
> -#define KS_WLAN_GET_PHY_TYPE SIOCIWFIRSTPRIV + 23
> -#define KS_WLAN_SET_CTS_MODE SIOCIWFIRSTPRIV + 24
> -#define KS_WLAN_GET_CTS_MODE SIOCIWFIRSTPRIV + 25
> -/*   SIOCIWFIRSTPRIV + 26 */
> -/*   SIOCIWFIRSTPRIV + 27 */
> -#define KS_WLAN_SET_SLEEP_MODE   SIOCIWFIRSTPRIV + 28/* 
> sleep mode */
> -#define KS_WLAN_GET_SLEEP_MODE   SIOCIWFIRSTPRIV + 29/* 
> sleep mode */
> -/*   SIOCIWFIRSTPRIV + 30 */
> -/*   SIOCIWFIRSTPRIV + 31 */
> +#define KS_WLAN_SET_PHY_TYPE (SIOCIWFIRSTPRIV + 22)
> +#define KS_WLAN_GET_PHY_TYPE (SIOCIWFIRSTPRIV + 23)
> +#define KS_WLAN_SET_CTS_MODE (SIOCIWFIRSTPRIV + 24)
> +#define KS_WLAN_GET_CTS_MODE (SIOCIWFIRSTPRIV + 25)
> +/*   (SIOCIWFIRSTPRIV + 26) */
> +/*   (SIOCIWFIRSTPRIV + 27) */
> +#define KS_WLAN_SET_SLEEP_MODE   (SIOCIWFIRSTPRIV + 28) /* sleep 
> mode */
> +#define KS_WLAN_GET_SLEEP_MODE   (SIOCIWFIRSTPRIV + 29) /* sleep 
> mode */
> +/*   (SIOCIWFIRSTPRIV + 30) */
> +/*   

pull request: linux-firmware: update cxgb4 firmware

[Ganesh Goudar]

Hi,

Kindly pull from the following URL?
git://git.chelsio.net/pub/git/linux-firmware.git for-upstream

The following changes since commit fedc06024bf7145a2338c5e38d376ebce2d20917:

  cxgb4: update firmware to revision 1.16.29.0 (2017-02-24 06:46:36 -0800)

are available in the git repository at:

  git://git.chelsio.net/pub/git/linux-firmware.git for-upstream

for you to fetch changes up to fedc06024bf7145a2338c5e38d376ebce2d20917:

  cxgb4: update firmware to revision 1.16.29.0 (2017-02-24 06:46:36 -0800)

pull request: linux-firmware: update cxgb4 firmware

[Ganesh Goudar]

Hi,

Kindly pull from the following URL?
git://git.chelsio.net/pub/git/linux-firmware.git for-upstream

The following changes since commit fedc06024bf7145a2338c5e38d376ebce2d20917:

  cxgb4: update firmware to revision 1.16.29.0 (2017-02-24 06:46:36 -0800)

are available in the git repository at:

  git://git.chelsio.net/pub/git/linux-firmware.git for-upstream

for you to fetch changes up to fedc06024bf7145a2338c5e38d376ebce2d20917:

  cxgb4: update firmware to revision 1.16.29.0 (2017-02-24 06:46:36 -0800)

Re: [PATCH] target/user: Add daynmic growing data area featuresupport

[Xiubo Li]

Cool. This is a good approach for an initial patch but this raises
concerns about efficiently managing kernel memory usage -- the data area
grows but never shrinks, and total possible usage increases per
backstore. (What if there are 1000?) Any ideas how we could also improve
these aspects of the design? (Global TCMU data area usage limit?)

Two ways in my mind:

The first:
How about by setting a threshold cmd(SHRINK cmd), something likes
the PAD cmd, to tell the userspace runner try to shrink the memories?

Why should userspace need to know if the kernel is shrinking memory
allocated to the data area? Userspace knows about memory described in
iovecs for in-flight cmds, we shouldn't need its cooperation to free
other allocated parts of the data area.

Yes.


But, We likely don't want to release memory from the data area anyways
while active, in any case. How about if we set a timer when active
commands go to zero, and then reduce data area to some minimum if no new
cmds come in before timer expires?


If I understand correctly: for example, we have 1G(as the minimum)
data area and all blocks have been allocated and mapped to runner's
vma, then we extern it to 1G + 256M as needed. When there have no
active cmds and after the timer expires, will it reduce the data area
back to 1G ? And then should it release the reduced 256M data area's
memories ?

If so, after kfree()ed the blocks' memories, it should also try to remove
all the ptes which are mapping this page(like using the try_to_umap()),
but something like try_to_umap() doesn't export for the modules.

Without ummaping the kfree()ed pages' ptes mentioned above, then
the reduced 256M vma space couldn't be reused again for the runner
process, because the runner has already do the mapping for the reduced
vma space to some old physical pages(won't trigger new page fault
again). Then there will be a hole, and the hole will be bigger and bigger.

Without ummaping the kfree()ed pages' ptes mentioned above, the
pages' reference count (page_ref_dec(), which _inc()ed in page fault)
couldn't be reduced back too.


When the runner get the SHRINK cmd, it will try to remmap uio0's ring
buffer(?). Then the kernel will get chance to shrink the memories

The second:
Try to extern the data area by using /dev/uio1, we could remmap the
uio1 device when need, so it will be easy to get a chance to shrink the
memories in uio1.

Userspace should not need to remap the region in order for the kernel to
free and unmap pages from the region.

The only thing we need to watch out for is if blocks are referenced by
in-flight cmds, we can't free them or userspace will segfault.

Yes, agree.


So, if we
wait until there are no in-flight cmds, then it follows that the kernel
can free whatever it wants and userspace will not segfault.

So, the problem is how to ummap the kfree()ed pages' ptes.


BRs
Xiubo


-- Andy

Re: [PATCH] target/user: Add daynmic growing data area featuresupport

[Xiubo Li]

Cool. This is a good approach for an initial patch but this raises
concerns about efficiently managing kernel memory usage -- the data area
grows but never shrinks, and total possible usage increases per
backstore. (What if there are 1000?) Any ideas how we could also improve
these aspects of the design? (Global TCMU data area usage limit?)

Two ways in my mind:

The first:
How about by setting a threshold cmd(SHRINK cmd), something likes
the PAD cmd, to tell the userspace runner try to shrink the memories?

Why should userspace need to know if the kernel is shrinking memory
allocated to the data area? Userspace knows about memory described in
iovecs for in-flight cmds, we shouldn't need its cooperation to free
other allocated parts of the data area.

Yes.


But, We likely don't want to release memory from the data area anyways
while active, in any case. How about if we set a timer when active
commands go to zero, and then reduce data area to some minimum if no new
cmds come in before timer expires?


If I understand correctly: for example, we have 1G(as the minimum)
data area and all blocks have been allocated and mapped to runner's
vma, then we extern it to 1G + 256M as needed. When there have no
active cmds and after the timer expires, will it reduce the data area
back to 1G ? And then should it release the reduced 256M data area's
memories ?

If so, after kfree()ed the blocks' memories, it should also try to remove
all the ptes which are mapping this page(like using the try_to_umap()),
but something like try_to_umap() doesn't export for the modules.

Without ummaping the kfree()ed pages' ptes mentioned above, then
the reduced 256M vma space couldn't be reused again for the runner
process, because the runner has already do the mapping for the reduced
vma space to some old physical pages(won't trigger new page fault
again). Then there will be a hole, and the hole will be bigger and bigger.

Without ummaping the kfree()ed pages' ptes mentioned above, the
pages' reference count (page_ref_dec(), which _inc()ed in page fault)
couldn't be reduced back too.


When the runner get the SHRINK cmd, it will try to remmap uio0's ring
buffer(?). Then the kernel will get chance to shrink the memories

The second:
Try to extern the data area by using /dev/uio1, we could remmap the
uio1 device when need, so it will be easy to get a chance to shrink the
memories in uio1.

Userspace should not need to remap the region in order for the kernel to
free and unmap pages from the region.

The only thing we need to watch out for is if blocks are referenced by
in-flight cmds, we can't free them or userspace will segfault.

Yes, agree.


So, if we
wait until there are no in-flight cmds, then it follows that the kernel
can free whatever it wants and userspace will not segfault.

So, the problem is how to ummap the kfree()ed pages' ptes.


BRs
Xiubo


-- Andy

Re: [platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Jonathan Woithe]

On Mon, Feb 27, 2017 at 12:58:40PM +0800, Fengguang Wu wrote:
> Here is another bisect result. The attached reproduce-* script may
> help debug the issue.

Thanks for this.  FYI the cause of this issue is already understood (refer
to previous linux-platform-driver ML discussions).  The relevant part of the
patch series (08/10) has been (or will be) reverted by Andy to resolve the
problem for the moment (as per my earlier email).  The issue that part 08/10
was aiming to fix will be addressed in a more complete way in a follow up
patch series from Michael in due course as explained in my Reviewed-by
comment.

Regards
  jonathan

Re: [platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Jonathan Woithe]

On Mon, Feb 27, 2017 at 12:58:40PM +0800, Fengguang Wu wrote:
> Here is another bisect result. The attached reproduce-* script may
> help debug the issue.

Thanks for this.  FYI the cause of this issue is already understood (refer
to previous linux-platform-driver ML discussions).  The relevant part of the
patch series (08/10) has been (or will be) reverted by Andy to resolve the
problem for the moment (as per my earlier email).  The issue that part 08/10
was aiming to fix will be addressed in a more complete way in a follow up
patch series from Michael in due course as explained in my Reviewed-by
comment.

Regards
  jonathan

[REGRESSION] pinctrl, of, unable to find hogs

[Mika Penttilä]

With current linus git (pre 4.11), unable to find the pinctrl hogs :


 imx6q-pinctrl 20e.iomuxc: unable to find group for node hoggrp


Device is i.MX6 based.


--Mika

[PATCH] kbuild: avoid unrecognized option error for external DTC

[Masahiro Yamada]

Since commit 6b22b3d1614a ("kbuild: Allow using host dtc instead of
kernel's copy"), it is possible to use an external dtc.  In this
case, we do not know which options are supported on it.

Commit bc553986a2f7 ("dtc: turn off dtc unit address warnings by
default") gives -Wno-unit_address_vs_reg, but this options is only
recognized by v1.4.2 or later.

If an older version is specified, the build fails:

$ dtc --version
Version: DTC 1.4.0
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- DTC=dtc dtbs
  [ snip ]
  DTC arch/arm64/boot/dts/al/alpine-v2-evp.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
make[2]: *** [arch/arm64/boot/dts/al/alpine-v2-evp.dtb] Error 1
make[1]: *** [arch/arm64/boot/dts/al] Error 2
make: *** [dtbs] Error 2

This commit adds a new helper dtc-option to check if the given
option is supported, like cc-option, ld-option, etc.

The check for the -Wno-unit_address_vs_reg has been moved from
Makefile.lib to Makefile.extrawarn.  Since Makefile.lib is included
recursively, it is not efficient to evaluate the $(call dtc-option)
at every descend.  On the other hand, Makefile.extrawarn is included
just once from the top Makefile.  Besides, it seems more suitable to
collect extra warning things into the Makefile.extrawarn.

The variable, DTC, has also been moved to the top Makefile so that
the Makefile.extrawarn can reference it.

Here is one problem for the dtc-option helper; the kernel's copy
(scripts/dtc/dtc) is not compiled until Kbuild descends into the
scripts/dtc/ directory.  This happens later after Makefile.extrawarn
is evaluated.  So, dtc-options should its job only when DTC is
overridden from the command line (i.e. pre-built dtc is used).
If the kernel's copy is used, dtc-option falls back to a fixed option
because we know which options are supported on the internal one.

Signed-off-by: Masahiro Yamada 
---

 Makefile  |  4 +++-
 arch/c6x/boot/dts/Makefile|  2 +-
 arch/microblaze/boot/dts/Makefile |  2 +-
 arch/openrisc/boot/dts/Makefile   |  2 +-
 arch/powerpc/boot/Makefile|  2 +-
 scripts/Kbuild.include| 14 ++
 scripts/Makefile.extrawarn|  4 
 scripts/Makefile.lib  |  6 --
 8 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index b83109b..4c4647a 100644
--- a/Makefile
+++ b/Makefile
@@ -356,6 +356,7 @@ STRIP   = $(CROSS_COMPILE)strip
 OBJCOPY= $(CROSS_COMPILE)objcopy
 OBJDUMP= $(CROSS_COMPILE)objdump
 AWK= awk
+DTC= scripts/dtc/dtc
 GENKSYMS   = scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
 DEPMOD = /sbin/depmod
@@ -365,6 +366,7 @@ CHECK   = sparse
 
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
  -Wbitwise -Wno-return-void $(CF)
+DTC_FLAGS  :=
 NOSTDINC_FLAGS  =
 CFLAGS_MODULE   =
 AFLAGS_MODULE   =
@@ -419,7 +421,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE 
KERNELVERSION
 export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP
 export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
-export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
+export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS DTC DTC_FLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
 export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV 
CFLAGS_KASAN CFLAGS_UBSAN
diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index c7528b0..459955b 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -2,7 +2,7 @@
 # Makefile for device trees
 #
 
-DTC_FLAGS ?= -p 1024
+DTC_FLAGS += -p 1024
 
 ifneq ($(DTB),)
 obj-y += linked_dtb.o
diff --git a/arch/microblaze/boot/dts/Makefile 
b/arch/microblaze/boot/dts/Makefile
index a3d2e42..5addb5b 100644
--- a/arch/microblaze/boot/dts/Makefile
+++ b/arch/microblaze/boot/dts/Makefile
@@ -15,4 +15,4 @@ quiet_cmd_cp = CP  $< $@$2
cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
 
 # Rule to build device tree blobs
-DTC_FLAGS := -p 1024
+DTC_FLAGS += -p 1024
diff --git a/arch/openrisc/boot/dts/Makefile b/arch/openrisc/boot/dts/Makefile
index b092d30..f4048d1 100644
--- a/arch/openrisc/boot/dts/Makefile
+++ b/arch/openrisc/boot/dts/Makefile
@@ -7,4 +7,4 @@ obj-y += $(BUILTIN_DTB)
 
 clean-files := *.dtb.S
 
-#DTC_FLAGS ?= -p 1024
+#DTC_FLAGS += -p 1024
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e82f333..5350b67 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -50,7 +50,7 @@ endif
 
 BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj)
 
-DTC_FLAGS  ?= -p 1024
+DTC_FLAGS  += -p 1024
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
diff --git a/scripts/Kbuild.include 

[REGRESSION] pinctrl, of, unable to find hogs

[Mika Penttilä]

With current linus git (pre 4.11), unable to find the pinctrl hogs :


 imx6q-pinctrl 20e.iomuxc: unable to find group for node hoggrp


Device is i.MX6 based.


--Mika

[PATCH] kbuild: avoid unrecognized option error for external DTC

[Masahiro Yamada]

Since commit 6b22b3d1614a ("kbuild: Allow using host dtc instead of
kernel's copy"), it is possible to use an external dtc.  In this
case, we do not know which options are supported on it.

Commit bc553986a2f7 ("dtc: turn off dtc unit address warnings by
default") gives -Wno-unit_address_vs_reg, but this options is only
recognized by v1.4.2 or later.

If an older version is specified, the build fails:

$ dtc --version
Version: DTC 1.4.0
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- DTC=dtc dtbs
  [ snip ]
  DTC arch/arm64/boot/dts/al/alpine-v2-evp.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
make[2]: *** [arch/arm64/boot/dts/al/alpine-v2-evp.dtb] Error 1
make[1]: *** [arch/arm64/boot/dts/al] Error 2
make: *** [dtbs] Error 2

This commit adds a new helper dtc-option to check if the given
option is supported, like cc-option, ld-option, etc.

The check for the -Wno-unit_address_vs_reg has been moved from
Makefile.lib to Makefile.extrawarn.  Since Makefile.lib is included
recursively, it is not efficient to evaluate the $(call dtc-option)
at every descend.  On the other hand, Makefile.extrawarn is included
just once from the top Makefile.  Besides, it seems more suitable to
collect extra warning things into the Makefile.extrawarn.

The variable, DTC, has also been moved to the top Makefile so that
the Makefile.extrawarn can reference it.

Here is one problem for the dtc-option helper; the kernel's copy
(scripts/dtc/dtc) is not compiled until Kbuild descends into the
scripts/dtc/ directory.  This happens later after Makefile.extrawarn
is evaluated.  So, dtc-options should its job only when DTC is
overridden from the command line (i.e. pre-built dtc is used).
If the kernel's copy is used, dtc-option falls back to a fixed option
because we know which options are supported on the internal one.

Signed-off-by: Masahiro Yamada 
---

 Makefile  |  4 +++-
 arch/c6x/boot/dts/Makefile|  2 +-
 arch/microblaze/boot/dts/Makefile |  2 +-
 arch/openrisc/boot/dts/Makefile   |  2 +-
 arch/powerpc/boot/Makefile|  2 +-
 scripts/Kbuild.include| 14 ++
 scripts/Makefile.extrawarn|  4 
 scripts/Makefile.lib  |  6 --
 8 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index b83109b..4c4647a 100644
--- a/Makefile
+++ b/Makefile
@@ -356,6 +356,7 @@ STRIP   = $(CROSS_COMPILE)strip
 OBJCOPY= $(CROSS_COMPILE)objcopy
 OBJDUMP= $(CROSS_COMPILE)objdump
 AWK= awk
+DTC= scripts/dtc/dtc
 GENKSYMS   = scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
 DEPMOD = /sbin/depmod
@@ -365,6 +366,7 @@ CHECK   = sparse
 
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
  -Wbitwise -Wno-return-void $(CF)
+DTC_FLAGS  :=
 NOSTDINC_FLAGS  =
 CFLAGS_MODULE   =
 AFLAGS_MODULE   =
@@ -419,7 +421,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE 
KERNELVERSION
 export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP
 export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
-export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
+export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS DTC DTC_FLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
 export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV 
CFLAGS_KASAN CFLAGS_UBSAN
diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index c7528b0..459955b 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -2,7 +2,7 @@
 # Makefile for device trees
 #
 
-DTC_FLAGS ?= -p 1024
+DTC_FLAGS += -p 1024
 
 ifneq ($(DTB),)
 obj-y += linked_dtb.o
diff --git a/arch/microblaze/boot/dts/Makefile 
b/arch/microblaze/boot/dts/Makefile
index a3d2e42..5addb5b 100644
--- a/arch/microblaze/boot/dts/Makefile
+++ b/arch/microblaze/boot/dts/Makefile
@@ -15,4 +15,4 @@ quiet_cmd_cp = CP  $< $@$2
cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
 
 # Rule to build device tree blobs
-DTC_FLAGS := -p 1024
+DTC_FLAGS += -p 1024
diff --git a/arch/openrisc/boot/dts/Makefile b/arch/openrisc/boot/dts/Makefile
index b092d30..f4048d1 100644
--- a/arch/openrisc/boot/dts/Makefile
+++ b/arch/openrisc/boot/dts/Makefile
@@ -7,4 +7,4 @@ obj-y += $(BUILTIN_DTB)
 
 clean-files := *.dtb.S
 
-#DTC_FLAGS ?= -p 1024
+#DTC_FLAGS += -p 1024
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e82f333..5350b67 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -50,7 +50,7 @@ endif
 
 BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj)
 
-DTC_FLAGS  ?= -p 1024
+DTC_FLAGS  += -p 1024
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index d6ca649..adabbb5 

stack frame unwindind KASAN errors

[Daniel J Blueman]

On 4.9.13 with KASAN enabled [1], we see a number of stack unwinding
errors reported [2,3].

This seems to occur at half of boots.

Let me know for further debug info/patch testing and thanks,
  Daniel

[1] https://quora.org/config
[2] https://quora.org/dmesg.txt

-- [3]

BUG: KASAN: stack-out-of-bounds in
unwind_get_return_address+0x11d/0x130 at addr 881034eafa08
Read of size 8 by task systemd/1
page:ea0040d3abc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x2f8000()
page dumped because: kasan: bad access detected
CPU: 20 PID: 1 Comm: systemd Not tainted 4.9.13-debug+ #3
Hardware name: Supermicro Super Server/X10DRL-i, BIOS 2.0a 08/25/2016
 881c2f607a60 b0cdb541 881c2f607af8 881034eafa08
 881c2f607ae8 b064dd17 881034ea4f70 0024
  0286 881034ea4fe2 
Call Trace:
 
 [] dump_stack+0x85/0xc4
 [] kasan_report_error+0x4d7/0x500
 [] __asan_report_load8_noabort+0x61/0x70
 [] ? unwind_get_return_address+0x11d/0x130
 [] unwind_get_return_address+0x11d/0x130
 [] ? unwind_next_frame+0x97/0xf0
 [] __save_stack_trace+0x92/0x100
 [] ? file_free_rcu+0x46/0x60
 [] save_stack_trace+0x1b/0x20
 [] save_stack+0x46/0xd0
 [] ? save_stack_trace+0x1b/0x20
 [] ? save_stack+0x46/0xd0
 [] ? kasan_slab_free+0x71/0xb0
 [] ? kmem_cache_free+0xc4/0x350
 [] ? file_free_rcu+0x46/0x60
 [] ? rcu_process_callbacks+0x9d2/0x1220
 [] ? __do_softirq+0x286/0x87d
 [] ? irq_exit+0x160/0x190
 [] ? smp_apic_timer_interrupt+0x80/0xa0
 [] ? apic_timer_interrupt+0x8c/0xa0
 [] ? debug_check_no_locks_freed+0x290/0x290
 [] ? debug_object_deactivate+0xf8/0x320
 [] ? _raw_spin_unlock_irqrestore+0x5f/0x80
 [] ? trace_hardirqs_on_caller+0x19e/0x580
 [] ? _raw_spin_unlock_irqrestore+0x4a/0x80
 [] ? mark_held_locks+0xc8/0x120
 [] ? kmem_cache_free+0xaf/0x350
 [] ? file_free_rcu+0x46/0x60
 [] kasan_slab_free+0x71/0xb0
 [] kmem_cache_free+0xc4/0x350
 [] file_free_rcu+0x46/0x60
 [] rcu_process_callbacks+0x9d2/0x1220
 [] ? rcu_process_callbacks+0x97d/0x1220
 [] ? get_max_files+0x20/0x20
 [] __do_softirq+0x286/0x87d
 [] irq_exit+0x160/0x190
 [] smp_apic_timer_interrupt+0x80/0xa0
 [] apic_timer_interrupt+0x8c/0xa0
 
 [] ? save_stack+0x46/0xd0
 [] ? debug_check_no_locks_freed+0x290/0x290
 [] ? mark_held_locks+0xc8/0x120
 [] ? efi_call+0x58/0x90
 [] ? virt_efi_get_variable+0x9c/0x150
 [] ? efivar_entry_size+0xa4/0x110
 [] ? efivarfs_callback+0x30f/0x4e7
 [] ? efivarfs_evict_inode+0x10/0x10
 [] mark_held_locks+0xc8/0x120
 [] ? _raw_spin_unlock_irqrestore+0x5f/0x80
 [] ? _raw_spin_unlock_irqrestore+0x4a/0x80
 [] ? efivar_init+0x512/0x750
 [] ? efivarfs_evict_inode+0x10/0x10
 [] ? efivar_entry_iter+0x140/0x140
 [] ? debug_lockdep_rcu_enabled+0x77/0x90
 [] ? d_instantiate+0x6f/0x80
 [] ? _raw_spin_unlock+0x31/0x50
 [] ? _raw_spin_unlock+0x31/0x50
 [] ? d_instantiate+0x6f/0x80
 [] ? efivarfs_mount+0x20/0x20
 [] ? efivarfs_fill_super+0x1ea/0x290
 [] ? efivarfs_mount+0x20/0x20
 [] ? mount_single+0xcc/0x130
 [] ? efivarfs_mount+0x18/0x20
 [] ? mount_fs+0x81/0x2c0
 [] ? alloc_vfsmnt+0x451/0x720
 [] ? vfs_kern_mount+0x6b/0x370
 [] ? do_mount+0x355/0x2af0
 [] ? debug_lockdep_rcu_enabled+0x77/0x90
 [] ? copy_mount_string+0x20/0x20
 [] ? __might_fault+0xf6/0x1b0
 [] ? __check_object_size+0x1b4/0x3fe
 [] ? memdup_user+0x6b/0xa0
 [] ? SyS_mount+0x95/0xe0
 [] ? entry_SYSCALL_64_fastpath+0x23/0xc6
Memory state around the buggy address:
 881034eaf900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 881034eaf980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
>881034eafa00: f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f3 f3
   ^
 881034eafa80: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 881034eafb00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4
Disabling lock debugging due to kernel taint
-- 
Daniel J Blueman

stack frame unwindind KASAN errors

[Daniel J Blueman]

On 4.9.13 with KASAN enabled [1], we see a number of stack unwinding
errors reported [2,3].

This seems to occur at half of boots.

Let me know for further debug info/patch testing and thanks,
  Daniel

[1] https://quora.org/config
[2] https://quora.org/dmesg.txt

-- [3]

BUG: KASAN: stack-out-of-bounds in
unwind_get_return_address+0x11d/0x130 at addr 881034eafa08
Read of size 8 by task systemd/1
page:ea0040d3abc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x2f8000()
page dumped because: kasan: bad access detected
CPU: 20 PID: 1 Comm: systemd Not tainted 4.9.13-debug+ #3
Hardware name: Supermicro Super Server/X10DRL-i, BIOS 2.0a 08/25/2016
 881c2f607a60 b0cdb541 881c2f607af8 881034eafa08
 881c2f607ae8 b064dd17 881034ea4f70 0024
  0286 881034ea4fe2 
Call Trace:
 
 [] dump_stack+0x85/0xc4
 [] kasan_report_error+0x4d7/0x500
 [] __asan_report_load8_noabort+0x61/0x70
 [] ? unwind_get_return_address+0x11d/0x130
 [] unwind_get_return_address+0x11d/0x130
 [] ? unwind_next_frame+0x97/0xf0
 [] __save_stack_trace+0x92/0x100
 [] ? file_free_rcu+0x46/0x60
 [] save_stack_trace+0x1b/0x20
 [] save_stack+0x46/0xd0
 [] ? save_stack_trace+0x1b/0x20
 [] ? save_stack+0x46/0xd0
 [] ? kasan_slab_free+0x71/0xb0
 [] ? kmem_cache_free+0xc4/0x350
 [] ? file_free_rcu+0x46/0x60
 [] ? rcu_process_callbacks+0x9d2/0x1220
 [] ? __do_softirq+0x286/0x87d
 [] ? irq_exit+0x160/0x190
 [] ? smp_apic_timer_interrupt+0x80/0xa0
 [] ? apic_timer_interrupt+0x8c/0xa0
 [] ? debug_check_no_locks_freed+0x290/0x290
 [] ? debug_object_deactivate+0xf8/0x320
 [] ? _raw_spin_unlock_irqrestore+0x5f/0x80
 [] ? trace_hardirqs_on_caller+0x19e/0x580
 [] ? _raw_spin_unlock_irqrestore+0x4a/0x80
 [] ? mark_held_locks+0xc8/0x120
 [] ? kmem_cache_free+0xaf/0x350
 [] ? file_free_rcu+0x46/0x60
 [] kasan_slab_free+0x71/0xb0
 [] kmem_cache_free+0xc4/0x350
 [] file_free_rcu+0x46/0x60
 [] rcu_process_callbacks+0x9d2/0x1220
 [] ? rcu_process_callbacks+0x97d/0x1220
 [] ? get_max_files+0x20/0x20
 [] __do_softirq+0x286/0x87d
 [] irq_exit+0x160/0x190
 [] smp_apic_timer_interrupt+0x80/0xa0
 [] apic_timer_interrupt+0x8c/0xa0
 
 [] ? save_stack+0x46/0xd0
 [] ? debug_check_no_locks_freed+0x290/0x290
 [] ? mark_held_locks+0xc8/0x120
 [] ? efi_call+0x58/0x90
 [] ? virt_efi_get_variable+0x9c/0x150
 [] ? efivar_entry_size+0xa4/0x110
 [] ? efivarfs_callback+0x30f/0x4e7
 [] ? efivarfs_evict_inode+0x10/0x10
 [] mark_held_locks+0xc8/0x120
 [] ? _raw_spin_unlock_irqrestore+0x5f/0x80
 [] ? _raw_spin_unlock_irqrestore+0x4a/0x80
 [] ? efivar_init+0x512/0x750
 [] ? efivarfs_evict_inode+0x10/0x10
 [] ? efivar_entry_iter+0x140/0x140
 [] ? debug_lockdep_rcu_enabled+0x77/0x90
 [] ? d_instantiate+0x6f/0x80
 [] ? _raw_spin_unlock+0x31/0x50
 [] ? _raw_spin_unlock+0x31/0x50
 [] ? d_instantiate+0x6f/0x80
 [] ? efivarfs_mount+0x20/0x20
 [] ? efivarfs_fill_super+0x1ea/0x290
 [] ? efivarfs_mount+0x20/0x20
 [] ? mount_single+0xcc/0x130
 [] ? efivarfs_mount+0x18/0x20
 [] ? mount_fs+0x81/0x2c0
 [] ? alloc_vfsmnt+0x451/0x720
 [] ? vfs_kern_mount+0x6b/0x370
 [] ? do_mount+0x355/0x2af0
 [] ? debug_lockdep_rcu_enabled+0x77/0x90
 [] ? copy_mount_string+0x20/0x20
 [] ? __might_fault+0xf6/0x1b0
 [] ? __check_object_size+0x1b4/0x3fe
 [] ? memdup_user+0x6b/0xa0
 [] ? SyS_mount+0x95/0xe0
 [] ? entry_SYSCALL_64_fastpath+0x23/0xc6
Memory state around the buggy address:
 881034eaf900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 881034eaf980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
>881034eafa00: f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f3 f3
   ^
 881034eafa80: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 881034eafb00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4
Disabling lock debugging due to kernel taint
-- 
Daniel J Blueman

Re: [PATCH V3 0/4] Define coherent device memory node

[Anshuman Khandual]

On 02/27/2017 07:26 AM, Bob Liu wrote:
> On 2017/2/24 12:53, Jerome Glisse wrote:
>> On Fri, Feb 24, 2017 at 09:06:19AM +0800, Bob Liu wrote:
>>> On 2017/2/21 21:39, Anshuman Khandual wrote:
 On 02/21/2017 04:41 PM, Michal Hocko wrote:
> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote:
> [...]
>> * User space using mbind() to get CDM memory is an additional benefit
>>   we get by making the CDM plug in as a node and be part of the buddy
>>   allocator. But the over all idea from the user space point of view
>>   is that the application can allocate any generic buffer and try to
>>   use the buffer either from the CPU side or from the device without
>>   knowing about where the buffer is really mapped physically. That
>>   gives a seamless and transparent view to the user space where CPU
>>   compute and possible device based compute can work together. This
>>   is not possible through a driver allocated buffer.
>
> But how are you going to define any policy around that. Who is allowed

 The user space VMA can define the policy with a mbind(MPOL_BIND) call
 with CDM/CDMs in the nodemask.

> to allocate and how much of this "special memory". Is it possible that

 Any user space application with mbind(MPOL_BIND) call with CDM/CDMs in
 the nodemask can allocate from the CDM memory. "How much" gets controlled
 by how we fault from CPU and the default behavior of the buddy allocator.

> we will eventually need some access control mechanism? If yes then mbind

 No access control mechanism is needed. If an application wants to use
 CDM memory by specifying in the mbind() it can. Nothing prevents it
 from using the CDM memory.

> is really not suitable interface to (ab)use. Also what should happen if
> the mbind mentions only CDM memory and that is depleted?

 IIUC *only CDM* cannot be requested from user space as there are no user
 visible interface which can translate to __GFP_THISNODE. MPOL_BIND with
 CDM in the nodemask will eventually pick a FALLBACK zonelist which will
 have zones of the system including CDM ones. If the resultant CDM zones
 run out of memory, we fail the allocation request as usual.

>
> Could you also explain why the transparent view is really better than
> using a device specific mmap (aka CDM awareness)?

 Okay with a transparent view, we can achieve a control flow of application
 like the following.

 (1) Allocate a buffer: alloc_buffer(buf, size)
 (2) CPU compute on buffer: cpu_compute(buf, size)
 (3) Device compute on buffer:  device_compute(buf, size)
 (4) CPU compute on buffer: cpu_compute(buf, size)
 (5) Release the buffer:release_buffer(buf, size)

 With assistance from a device specific driver, the actual page mapping of
 the buffer can change between system RAM and device memory depending on
 which side is accessing at a given point. This will be achieved through
 driver initiated migrations.

>>>
>>> Sorry, I'm a bit confused here.
>>> What's the difference with the Heterogeneous memory management?
>>> Which also "allows to use device memory transparently inside any process
>>> without any modifications to process program code."
>>
>> HMM is first and foremost for platform (like Intel) where CPU can not
>> access device memory in cache coherent way or at all. CDM is for more
>> advance platform with a system bus that allow the CPU to access device
>> memory in cache coherent way.
>>
>> Hence CDM was design to integrate more closely in existing concept like
>> NUMA. From my point of view it is like another level in the memory
>> hierarchy. Nowaday you have local node memory and other node memory.
>> In not too distant future you will have fast CPU on die memory, local
>> memory (you beloved DDR3/DDR4), slightly slower but gigantic persistant
>> memory and also device memory (all those local to a node).
>>
>> On top of that you will still have the regular NUMA hierarchy between
>> nodes. But each node will have its own local hierarchy of memory.
>>
>> CDM wants to integrate with existing memory hinting API and i believe
>> this is needed to get some experience with how end user might want to
>> use this to fine tune their application.
>>
>> Some bit of HMM are generic and will be reuse by CDM, for instance the
>> DMA capable memory migration helpers. Wether they can also share HMM
>> approach of using ZONE_DEVICE is yet to be proven but it comes with
>> limitations (can't be on lru or have device lru) that might hinder a
>> closer integration of CDM memory with many aspect of kernel mm.
>>
>>
>> This is my own view and it likely differ in some way from the view of
>> the people behind CDM :)
>>
> 
> Got it, thank you for the kindly explanation.
> And also thank you, John.

Thanks Jerome and John for helping out with the 

Re: [PATCH V3 0/4] Define coherent device memory node

[Anshuman Khandual]

On 02/27/2017 07:26 AM, Bob Liu wrote:
> On 2017/2/24 12:53, Jerome Glisse wrote:
>> On Fri, Feb 24, 2017 at 09:06:19AM +0800, Bob Liu wrote:
>>> On 2017/2/21 21:39, Anshuman Khandual wrote:
 On 02/21/2017 04:41 PM, Michal Hocko wrote:
> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote:
> [...]
>> * User space using mbind() to get CDM memory is an additional benefit
>>   we get by making the CDM plug in as a node and be part of the buddy
>>   allocator. But the over all idea from the user space point of view
>>   is that the application can allocate any generic buffer and try to
>>   use the buffer either from the CPU side or from the device without
>>   knowing about where the buffer is really mapped physically. That
>>   gives a seamless and transparent view to the user space where CPU
>>   compute and possible device based compute can work together. This
>>   is not possible through a driver allocated buffer.
>
> But how are you going to define any policy around that. Who is allowed

 The user space VMA can define the policy with a mbind(MPOL_BIND) call
 with CDM/CDMs in the nodemask.

> to allocate and how much of this "special memory". Is it possible that

 Any user space application with mbind(MPOL_BIND) call with CDM/CDMs in
 the nodemask can allocate from the CDM memory. "How much" gets controlled
 by how we fault from CPU and the default behavior of the buddy allocator.

> we will eventually need some access control mechanism? If yes then mbind

 No access control mechanism is needed. If an application wants to use
 CDM memory by specifying in the mbind() it can. Nothing prevents it
 from using the CDM memory.

> is really not suitable interface to (ab)use. Also what should happen if
> the mbind mentions only CDM memory and that is depleted?

 IIUC *only CDM* cannot be requested from user space as there are no user
 visible interface which can translate to __GFP_THISNODE. MPOL_BIND with
 CDM in the nodemask will eventually pick a FALLBACK zonelist which will
 have zones of the system including CDM ones. If the resultant CDM zones
 run out of memory, we fail the allocation request as usual.

>
> Could you also explain why the transparent view is really better than
> using a device specific mmap (aka CDM awareness)?

 Okay with a transparent view, we can achieve a control flow of application
 like the following.

 (1) Allocate a buffer: alloc_buffer(buf, size)
 (2) CPU compute on buffer: cpu_compute(buf, size)
 (3) Device compute on buffer:  device_compute(buf, size)
 (4) CPU compute on buffer: cpu_compute(buf, size)
 (5) Release the buffer:release_buffer(buf, size)

 With assistance from a device specific driver, the actual page mapping of
 the buffer can change between system RAM and device memory depending on
 which side is accessing at a given point. This will be achieved through
 driver initiated migrations.

>>>
>>> Sorry, I'm a bit confused here.
>>> What's the difference with the Heterogeneous memory management?
>>> Which also "allows to use device memory transparently inside any process
>>> without any modifications to process program code."
>>
>> HMM is first and foremost for platform (like Intel) where CPU can not
>> access device memory in cache coherent way or at all. CDM is for more
>> advance platform with a system bus that allow the CPU to access device
>> memory in cache coherent way.
>>
>> Hence CDM was design to integrate more closely in existing concept like
>> NUMA. From my point of view it is like another level in the memory
>> hierarchy. Nowaday you have local node memory and other node memory.
>> In not too distant future you will have fast CPU on die memory, local
>> memory (you beloved DDR3/DDR4), slightly slower but gigantic persistant
>> memory and also device memory (all those local to a node).
>>
>> On top of that you will still have the regular NUMA hierarchy between
>> nodes. But each node will have its own local hierarchy of memory.
>>
>> CDM wants to integrate with existing memory hinting API and i believe
>> this is needed to get some experience with how end user might want to
>> use this to fine tune their application.
>>
>> Some bit of HMM are generic and will be reuse by CDM, for instance the
>> DMA capable memory migration helpers. Wether they can also share HMM
>> approach of using ZONE_DEVICE is yet to be proven but it comes with
>> limitations (can't be on lru or have device lru) that might hinder a
>> closer integration of CDM memory with many aspect of kernel mm.
>>
>>
>> This is my own view and it likely differ in some way from the view of
>> the people behind CDM :)
>>
> 
> Got it, thank you for the kindly explanation.
> And also thank you, John.

Thanks Jerome and John for helping out with the 

[v2 PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

Commit 09206b600c76 ("powernv: Pass PSSCR value and mask to
power9_idle_stop") added additional code in power_enter_stop() to
distinguish between stop requests whose PSSCR had ESL=EC=1 from those
which did not. When ESL=EC=1, we do a forward-jump to a location
labelled by "1", which had the code to handle the ESL=EC=1 case.

Unforunately just a couple of instructions before this label, is the
macro IDLE_STATE_ENTER_SEQ() which also has a label "1" in its
expansion.

As a result, the current code can result in directly executing stop
instruction for deep stop requests with PSSCR ESL=EC=1, without saving
the hypervisor state.

Fix this BUG by labeling the location that handles ESL=EC=1 case with
a more descriptive label ".Lhandle_esl_ec_set" (local label suggestion
a la .Lxx from Anton Blanchard).

While at it, rename the label "2" labelling the location of the code
handling entry into deep stop states with ".Lhandle_deep_stop".

For a good measure, change the label in IDLE_STATE_ENTER_SEQ() macro
to an not-so commonly used value in order to avoid similar mishaps in
the future.

Fixes: 09206b600c76 ("powernv: Pass PSSCR value and mask to
power9_idle_stop")

Cc: Michael Neuling 
Cc: Vaidyanathan Srinivasan 
Cc: Michael Ellerman 
Signed-off-by: Gautham R. Shenoy 
---
Changes from v1: 
  a) Use local label style for the updated descriptive label names.
  b) Add descriptive label to code handling entry into deep stop states.

 arch/powerpc/include/asm/cpuidle.h |  4 ++--
 arch/powerpc/kernel/idle_book3s.S  | 10 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 31192d8..3989d94 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -85,8 +85,8 @@ static inline void report_invalid_psscr_val(u64 psscr_val, 
int err)
std r0,0(r1);   \
ptesync;\
ld  r0,0(r1);   \
-1: cmpdcr0,r0,r0;  \
-   bne 1b; \
+236:   cmpdcr0,r0,r0;  \
+   bne 236b;   \
IDLE_INST;  \
 
 #defineIDLE_STATE_ENTER_SEQ_NORET(IDLE_INST)   \
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 9f6bce5..28fcb39 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -276,19 +276,21 @@ power_enter_stop:
  */
andis.   r4,r3,PSSCR_EC_ESL_MASK_SHIFTED
clrldi   r3,r3,60 /* r3 = Bits[60:63] = Requested Level (RL) */
-   bne  1f
+   bne  .Lhandle_esl_ec_set
IDLE_STATE_ENTER_SEQ(PPC_STOP)
li  r3,0  /* Since we didn't lose state, return 0 */
b   pnv_wakeup_noloss
+
+.Lhandle_esl_ec_set:
 /*
  * Check if the requested state is a deep idle state.
  */
-1: LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
+   LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
ld  r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpdr3,r4
-   bge 2f
+   bge .Lhandle_deep_stop
IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
-2:
+.Lhandle_deep_stop:
 /*
  * Entering deep idle state.
  * Clear thread bit in PACA_CORE_IDLE_STATE, save SPRs to
-- 
1.9.4

[v2 PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

Commit 09206b600c76 ("powernv: Pass PSSCR value and mask to
power9_idle_stop") added additional code in power_enter_stop() to
distinguish between stop requests whose PSSCR had ESL=EC=1 from those
which did not. When ESL=EC=1, we do a forward-jump to a location
labelled by "1", which had the code to handle the ESL=EC=1 case.

Unforunately just a couple of instructions before this label, is the
macro IDLE_STATE_ENTER_SEQ() which also has a label "1" in its
expansion.

As a result, the current code can result in directly executing stop
instruction for deep stop requests with PSSCR ESL=EC=1, without saving
the hypervisor state.

Fix this BUG by labeling the location that handles ESL=EC=1 case with
a more descriptive label ".Lhandle_esl_ec_set" (local label suggestion
a la .Lxx from Anton Blanchard).

While at it, rename the label "2" labelling the location of the code
handling entry into deep stop states with ".Lhandle_deep_stop".

For a good measure, change the label in IDLE_STATE_ENTER_SEQ() macro
to an not-so commonly used value in order to avoid similar mishaps in
the future.

Fixes: 09206b600c76 ("powernv: Pass PSSCR value and mask to
power9_idle_stop")

Cc: Michael Neuling 
Cc: Vaidyanathan Srinivasan 
Cc: Michael Ellerman 
Signed-off-by: Gautham R. Shenoy 
---
Changes from v1: 
  a) Use local label style for the updated descriptive label names.
  b) Add descriptive label to code handling entry into deep stop states.

 arch/powerpc/include/asm/cpuidle.h |  4 ++--
 arch/powerpc/kernel/idle_book3s.S  | 10 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 31192d8..3989d94 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -85,8 +85,8 @@ static inline void report_invalid_psscr_val(u64 psscr_val, 
int err)
std r0,0(r1);   \
ptesync;\
ld  r0,0(r1);   \
-1: cmpdcr0,r0,r0;  \
-   bne 1b; \
+236:   cmpdcr0,r0,r0;  \
+   bne 236b;   \
IDLE_INST;  \
 
 #defineIDLE_STATE_ENTER_SEQ_NORET(IDLE_INST)   \
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 9f6bce5..28fcb39 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -276,19 +276,21 @@ power_enter_stop:
  */
andis.   r4,r3,PSSCR_EC_ESL_MASK_SHIFTED
clrldi   r3,r3,60 /* r3 = Bits[60:63] = Requested Level (RL) */
-   bne  1f
+   bne  .Lhandle_esl_ec_set
IDLE_STATE_ENTER_SEQ(PPC_STOP)
li  r3,0  /* Since we didn't lose state, return 0 */
b   pnv_wakeup_noloss
+
+.Lhandle_esl_ec_set:
 /*
  * Check if the requested state is a deep idle state.
  */
-1: LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
+   LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
ld  r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpdr3,r4
-   bge 2f
+   bge .Lhandle_deep_stop
IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
-2:
+.Lhandle_deep_stop:
 /*
  * Entering deep idle state.
  * Clear thread bit in PACA_CORE_IDLE_STATE, save SPRs to
-- 
1.9.4

Re: [platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Fengguang Wu]

On Mon, Feb 27, 2017 at 03:53:56PM +1030, Jonathan Woithe wrote:

On Mon, Feb 27, 2017 at 12:58:40PM +0800, Fengguang Wu wrote:

Here is another bisect result. The attached reproduce-* script may
help debug the issue.


Thanks for this.  FYI the cause of this issue is already understood (refer
to previous linux-platform-driver ML discussions).  The relevant part of the
patch series (08/10) has been (or will be) reverted by Andy to resolve the
problem for the moment (as per my earlier email).  The issue that part 08/10
was aiming to fix will be addressed in a more complete way in a follow up
patch series from Michael in due course as explained in my Reviewed-by
comment.


Good to know that, thank you for the info!

Regards,
Fengguang

Re: [platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Fengguang Wu]

On Mon, Feb 27, 2017 at 03:53:56PM +1030, Jonathan Woithe wrote:

On Mon, Feb 27, 2017 at 12:58:40PM +0800, Fengguang Wu wrote:

Here is another bisect result. The attached reproduce-* script may
help debug the issue.


Thanks for this.  FYI the cause of this issue is already understood (refer
to previous linux-platform-driver ML discussions).  The relevant part of the
patch series (08/10) has been (or will be) reverted by Andy to resolve the
problem for the moment (as per my earlier email).  The issue that part 08/10
was aiming to fix will be addressed in a more complete way in a follow up
patch series from Michael in due course as explained in my Reviewed-by
comment.


Good to know that, thank you for the info!

Regards,
Fengguang

Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

[Kishon Vijay Abraham I]

Hi,

On Thursday 23 February 2017 12:20 AM, Alim Akhtar wrote:
> On Fri, Feb 3, 2017 at 2:49 PM, Alim Akhtar  wrote:
>> Hi Kishon,
>>
>>
>> On 11/19/2015 07:09 PM, Kishon Vijay Abraham I wrote:
>>>
>>> Hi,
>>>
>>> On Tuesday 17 November 2015 01:41 PM, Alim Akhtar wrote:

 Hi
 Thanks again for looking into this.

 On 11/17/2015 11:46 AM, Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Monday 09 November 2015 10:56 AM, Alim Akhtar wrote:
>>
>> From: Seungwon Jeon 
>>
>> This patch introduces Exynos UFS PHY driver. This driver
>> supports to deal with phy calibration and power control
>> according to UFS host driver's behavior.
>>
>> Signed-off-by: Seungwon Jeon 
>> Signed-off-by: Alim Akhtar 
>> Cc: Kishon Vijay Abraham I 
>> ---
>>   drivers/phy/Kconfig|7 ++
>>   drivers/phy/Makefile   |1 +
>>   drivers/phy/phy-exynos-ufs.c   |  241
>> 
>>   drivers/phy/phy-exynos-ufs.h   |   85 +
>>   drivers/phy/phy-exynos7-ufs.h  |   89 +
>>   include/linux/phy/phy-exynos-ufs.h |   85 +
>>   6 files changed, 508 insertions(+)
>>   create mode 100644 drivers/phy/phy-exynos-ufs.c
>>   create mode 100644 drivers/phy/phy-exynos-ufs.h
>>   create mode 100644 drivers/phy/phy-exynos7-ufs.h
>>   create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 7eb5859dd035..7d38a92e0297 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -389,4 +389,11 @@ config PHY_CYGNUS_PCIE
>> Enable this to support the Broadcom Cygnus PCIe PHY.
>> If unsure, say N.
>>
>> +config PHY_EXYNOS_UFS
>> +tristate "EXYNOS SoC series UFS PHY driver"
>> +depends on OF && ARCH_EXYNOS || COMPILE_TEST
>> +select GENERIC_PHY
>> +help
>> +  Support for UFS PHY on Samsung EXYNOS chipsets.
>> +
>>   endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 075db1a81aa5..9bec4d1a89e1 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+=
>> phy-armada375-usb2.o
>>   obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
>>   obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
>>   obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
>> +obj-$(CONFIG_PHY_EXYNOS_UFS)+= phy-exynos-ufs.o
>>   obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o
>>   obj-$(CONFIG_PHY_PXA_28NM_USB2)+= phy-pxa-28nm-usb2.o
>>   obj-$(CONFIG_PHY_PXA_28NM_HSIC)+= phy-pxa-28nm-hsic.o
>> diff --git a/drivers/phy/phy-exynos-ufs.c
>> b/drivers/phy/phy-exynos-ufs.c
>> new file mode 100644
>> index ..cb1aeaa3d4eb
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos-ufs.c
>> @@ -0,0 +1,241 @@
>> +/*
>> + * UFS PHY driver for Samsung EXYNOS SoC
>> + *
>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>> + * Author: Seungwon Jeon 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License as published
>> by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "phy-exynos-ufs.h"
>> +
>> +#define for_each_phy_lane(phy, i) \
>> +for (i = 0; i < (phy)->lane_cnt; i++)
>> +#define for_each_phy_cfg(cfg) \
>> +for (; (cfg)->id; (cfg)++)
>> +
>> +#define PHY_DEF_LANE_CNT1
>> +
>> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
>> +const struct exynos_ufs_phy_cfg *cfg, u8 lane)
>> +{
>> +enum {LANE_0, LANE_1}; /* lane index */
>> +
>> +switch (lane) {
>> +case LANE_0:
>> +writel(cfg->val, (phy)->reg_pma + cfg->off_0);
>> +break;
>> +case LANE_1:
>> +if (cfg->id == PHY_TRSV_BLK)
>> +writel(cfg->val, (phy)->reg_pma + cfg->off_1);
>> +break;
>> +}
>> +}
>> +
>> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
>> +{
>> +if (IS_PWR_MODE_ANY(desc))
>> +return true;
>> +
>> +if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))

Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

[Kishon Vijay Abraham I]

Hi,

On Thursday 23 February 2017 12:20 AM, Alim Akhtar wrote:
> On Fri, Feb 3, 2017 at 2:49 PM, Alim Akhtar  wrote:
>> Hi Kishon,
>>
>>
>> On 11/19/2015 07:09 PM, Kishon Vijay Abraham I wrote:
>>>
>>> Hi,
>>>
>>> On Tuesday 17 November 2015 01:41 PM, Alim Akhtar wrote:

 Hi
 Thanks again for looking into this.

 On 11/17/2015 11:46 AM, Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Monday 09 November 2015 10:56 AM, Alim Akhtar wrote:
>>
>> From: Seungwon Jeon 
>>
>> This patch introduces Exynos UFS PHY driver. This driver
>> supports to deal with phy calibration and power control
>> according to UFS host driver's behavior.
>>
>> Signed-off-by: Seungwon Jeon 
>> Signed-off-by: Alim Akhtar 
>> Cc: Kishon Vijay Abraham I 
>> ---
>>   drivers/phy/Kconfig|7 ++
>>   drivers/phy/Makefile   |1 +
>>   drivers/phy/phy-exynos-ufs.c   |  241
>> 
>>   drivers/phy/phy-exynos-ufs.h   |   85 +
>>   drivers/phy/phy-exynos7-ufs.h  |   89 +
>>   include/linux/phy/phy-exynos-ufs.h |   85 +
>>   6 files changed, 508 insertions(+)
>>   create mode 100644 drivers/phy/phy-exynos-ufs.c
>>   create mode 100644 drivers/phy/phy-exynos-ufs.h
>>   create mode 100644 drivers/phy/phy-exynos7-ufs.h
>>   create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 7eb5859dd035..7d38a92e0297 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -389,4 +389,11 @@ config PHY_CYGNUS_PCIE
>> Enable this to support the Broadcom Cygnus PCIe PHY.
>> If unsure, say N.
>>
>> +config PHY_EXYNOS_UFS
>> +tristate "EXYNOS SoC series UFS PHY driver"
>> +depends on OF && ARCH_EXYNOS || COMPILE_TEST
>> +select GENERIC_PHY
>> +help
>> +  Support for UFS PHY on Samsung EXYNOS chipsets.
>> +
>>   endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 075db1a81aa5..9bec4d1a89e1 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+=
>> phy-armada375-usb2.o
>>   obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
>>   obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
>>   obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
>> +obj-$(CONFIG_PHY_EXYNOS_UFS)+= phy-exynos-ufs.o
>>   obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o
>>   obj-$(CONFIG_PHY_PXA_28NM_USB2)+= phy-pxa-28nm-usb2.o
>>   obj-$(CONFIG_PHY_PXA_28NM_HSIC)+= phy-pxa-28nm-hsic.o
>> diff --git a/drivers/phy/phy-exynos-ufs.c
>> b/drivers/phy/phy-exynos-ufs.c
>> new file mode 100644
>> index ..cb1aeaa3d4eb
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos-ufs.c
>> @@ -0,0 +1,241 @@
>> +/*
>> + * UFS PHY driver for Samsung EXYNOS SoC
>> + *
>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>> + * Author: Seungwon Jeon 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License as published
>> by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "phy-exynos-ufs.h"
>> +
>> +#define for_each_phy_lane(phy, i) \
>> +for (i = 0; i < (phy)->lane_cnt; i++)
>> +#define for_each_phy_cfg(cfg) \
>> +for (; (cfg)->id; (cfg)++)
>> +
>> +#define PHY_DEF_LANE_CNT1
>> +
>> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
>> +const struct exynos_ufs_phy_cfg *cfg, u8 lane)
>> +{
>> +enum {LANE_0, LANE_1}; /* lane index */
>> +
>> +switch (lane) {
>> +case LANE_0:
>> +writel(cfg->val, (phy)->reg_pma + cfg->off_0);
>> +break;
>> +case LANE_1:
>> +if (cfg->id == PHY_TRSV_BLK)
>> +writel(cfg->val, (phy)->reg_pma + cfg->off_1);
>> +break;
>> +}
>> +}
>> +
>> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
>> +{
>> +if (IS_PWR_MODE_ANY(desc))
>> +return true;
>> +
>> +if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
>> +return true;
>> +
>> +if (COMP_PWR_MODE(required_pwr, desc))
>> +return true;

Re: [PATCH] PCI: dwc: Fix crashes seen due to missing assignments

[Kishon Vijay Abraham I]

Hi Guenter,

On Saturday 25 February 2017 03:38 PM, Guenter Roeck wrote:
> Fix the following crash, seen in dwc/pci-imx6.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 0070
> pgd = c0004000
> [0070] *pgd=
> Internal error: Oops: 805 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-09686-g9e31489 #1
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> task: cb85 task.stack: cb84e000
> PC is at imx6_pcie_probe+0x2f4/0x414
> ...
> 
> While at it, fix the same problem in various drivers instead of waiting
> for individual crash reports.
> 
> The change in the imx6 driver was tested with qemu. The changes in other
> drivers are based on code inspection and have been compile tested only.
> 
> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into ...")
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Guenter Roeck 

looks like I missed the assignment which rebasing. Thanks for fixing it.

Acked-by: Kishon Vijay Abraham I 

-Kishon
> ---
>  drivers/pci/dwc/pci-exynos.c | 1 +
>  drivers/pci/dwc/pci-imx6.c   | 1 +
>  drivers/pci/dwc/pci-keystone.c   | 2 ++
>  drivers/pci/dwc/pci-layerscape.c | 2 ++
>  drivers/pci/dwc/pcie-armada8k.c  | 2 ++
>  drivers/pci/dwc/pcie-artpec6.c   | 2 ++
>  drivers/pci/dwc/pcie-hisi.c  | 2 ++
>  drivers/pci/dwc/pcie-qcom.c  | 2 ++
>  drivers/pci/dwc/pcie-spear13xx.c | 2 ++
>  9 files changed, 16 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index 001c91a945aa..993b650ef275 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -668,6 +668,7 @@ static int __init exynos_pcie_probe(struct 
> platform_device *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + ep->pci = pci;
>   ep->ops = (const struct exynos_pcie_ops *)
>   of_device_get_match_data(dev);
>  
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index 3ab6761db9e8..801e46cd266d 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -605,6 +605,7 @@ static int __init imx6_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + imx6_pcie->pci = pci;
>   imx6_pcie->variant =
>   (enum imx6_pcie_variants)of_device_get_match_data(dev);
>  
> diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c
> index 8dc66409182d..fcc9723bad6e 100644
> --- a/drivers/pci/dwc/pci-keystone.c
> +++ b/drivers/pci/dwc/pci-keystone.c
> @@ -401,6 +401,8 @@ static int __init ks_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + ks_pcie->pci = pci;
> +
>   /* initialize SerDes Phy if present */
>   phy = devm_phy_get(dev, "pcie-phy");
>   if (PTR_ERR_OR_ZERO(phy) == -EPROBE_DEFER)
> diff --git a/drivers/pci/dwc/pci-layerscape.c 
> b/drivers/pci/dwc/pci-layerscape.c
> index 175c09e3a932..c32e392a0ae6 100644
> --- a/drivers/pci/dwc/pci-layerscape.c
> +++ b/drivers/pci/dwc/pci-layerscape.c
> @@ -280,6 +280,8 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = pcie->drvdata->dw_pcie_ops;
>  
> + pcie->pci = pci;
> +
>   dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>   pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>   if (IS_ERR(pci->dbi_base))
> diff --git a/drivers/pci/dwc/pcie-armada8k.c b/drivers/pci/dwc/pcie-armada8k.c
> index 66bac6fbfa9f..f110e3b24a26 100644
> --- a/drivers/pci/dwc/pcie-armada8k.c
> +++ b/drivers/pci/dwc/pcie-armada8k.c
> @@ -220,6 +220,8 @@ static int armada8k_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + pcie->pci = pci;
> +
>   pcie->clk = devm_clk_get(dev, NULL);
>   if (IS_ERR(pcie->clk))
>   return PTR_ERR(pcie->clk);
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index 59ecc9e66436..fcd3ef845883 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -253,6 +253,8 @@ static int artpec6_pcie_probe(struct platform_device 
> *pdev)
>  
>   pci->dev = dev;
>  
> + artpec6_pcie->pci = pci;
> +
>   dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>   pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>   if (IS_ERR(pci->dbi_base))
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index e3e4fedd9f68..fd66a3199db7 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -284,6 +284,8 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  
>   driver = dev->driver;
>  
> + hisi_pcie->pci = pci;
> +
>   hisi_pcie->soc_ops = of_device_get_match_data(dev);
>  
>   hisi_pcie->subctrl 

Re: [PATCH] PCI: dwc: Fix crashes seen due to missing assignments

[Kishon Vijay Abraham I]

Hi Guenter,

On Saturday 25 February 2017 03:38 PM, Guenter Roeck wrote:
> Fix the following crash, seen in dwc/pci-imx6.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 0070
> pgd = c0004000
> [0070] *pgd=
> Internal error: Oops: 805 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-09686-g9e31489 #1
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> task: cb85 task.stack: cb84e000
> PC is at imx6_pcie_probe+0x2f4/0x414
> ...
> 
> While at it, fix the same problem in various drivers instead of waiting
> for individual crash reports.
> 
> The change in the imx6 driver was tested with qemu. The changes in other
> drivers are based on code inspection and have been compile tested only.
> 
> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into ...")
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Guenter Roeck 

looks like I missed the assignment which rebasing. Thanks for fixing it.

Acked-by: Kishon Vijay Abraham I 

-Kishon
> ---
>  drivers/pci/dwc/pci-exynos.c | 1 +
>  drivers/pci/dwc/pci-imx6.c   | 1 +
>  drivers/pci/dwc/pci-keystone.c   | 2 ++
>  drivers/pci/dwc/pci-layerscape.c | 2 ++
>  drivers/pci/dwc/pcie-armada8k.c  | 2 ++
>  drivers/pci/dwc/pcie-artpec6.c   | 2 ++
>  drivers/pci/dwc/pcie-hisi.c  | 2 ++
>  drivers/pci/dwc/pcie-qcom.c  | 2 ++
>  drivers/pci/dwc/pcie-spear13xx.c | 2 ++
>  9 files changed, 16 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index 001c91a945aa..993b650ef275 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -668,6 +668,7 @@ static int __init exynos_pcie_probe(struct 
> platform_device *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + ep->pci = pci;
>   ep->ops = (const struct exynos_pcie_ops *)
>   of_device_get_match_data(dev);
>  
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index 3ab6761db9e8..801e46cd266d 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -605,6 +605,7 @@ static int __init imx6_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + imx6_pcie->pci = pci;
>   imx6_pcie->variant =
>   (enum imx6_pcie_variants)of_device_get_match_data(dev);
>  
> diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c
> index 8dc66409182d..fcc9723bad6e 100644
> --- a/drivers/pci/dwc/pci-keystone.c
> +++ b/drivers/pci/dwc/pci-keystone.c
> @@ -401,6 +401,8 @@ static int __init ks_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + ks_pcie->pci = pci;
> +
>   /* initialize SerDes Phy if present */
>   phy = devm_phy_get(dev, "pcie-phy");
>   if (PTR_ERR_OR_ZERO(phy) == -EPROBE_DEFER)
> diff --git a/drivers/pci/dwc/pci-layerscape.c 
> b/drivers/pci/dwc/pci-layerscape.c
> index 175c09e3a932..c32e392a0ae6 100644
> --- a/drivers/pci/dwc/pci-layerscape.c
> +++ b/drivers/pci/dwc/pci-layerscape.c
> @@ -280,6 +280,8 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = pcie->drvdata->dw_pcie_ops;
>  
> + pcie->pci = pci;
> +
>   dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>   pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>   if (IS_ERR(pci->dbi_base))
> diff --git a/drivers/pci/dwc/pcie-armada8k.c b/drivers/pci/dwc/pcie-armada8k.c
> index 66bac6fbfa9f..f110e3b24a26 100644
> --- a/drivers/pci/dwc/pcie-armada8k.c
> +++ b/drivers/pci/dwc/pcie-armada8k.c
> @@ -220,6 +220,8 @@ static int armada8k_pcie_probe(struct platform_device 
> *pdev)
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>  
> + pcie->pci = pci;
> +
>   pcie->clk = devm_clk_get(dev, NULL);
>   if (IS_ERR(pcie->clk))
>   return PTR_ERR(pcie->clk);
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index 59ecc9e66436..fcd3ef845883 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -253,6 +253,8 @@ static int artpec6_pcie_probe(struct platform_device 
> *pdev)
>  
>   pci->dev = dev;
>  
> + artpec6_pcie->pci = pci;
> +
>   dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>   pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
>   if (IS_ERR(pci->dbi_base))
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index e3e4fedd9f68..fd66a3199db7 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -284,6 +284,8 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  
>   driver = dev->driver;
>  
> + hisi_pcie->pci = pci;
> +
>   hisi_pcie->soc_ops = of_device_get_match_data(dev);
>  
>   hisi_pcie->subctrl =
> diff --git a/drivers/pci/dwc/pcie-qcom.c 

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs 
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write corrupts the 
file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0 
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2# 
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2# 

Thanks,
Xiong

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs 
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write corrupts the 
file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2# 
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0 
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097 
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2# 
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2# 

Thanks,
Xiong

Re: [PATCH 5/7] watchdog: s3c2410: Constify local structures

[Guenter Roeck]

On 02/24/2017 11:42 PM, Krzysztof Kozlowski wrote:

On Fri, Feb 24, 2017 at 02:05:56PM -0800, Guenter Roeck wrote:

On 02/24/2017 01:07 PM, Krzysztof Kozlowski wrote:

Structures watchdog_device, watchdog_ops and s3c2410_wdt_variant are not
modified so they can be made const to increase code safeness.

Signed-off-by: Krzysztof Kozlowski 


Conflicts with "watchdog: constify watchdog_ops structures" in my tree.
I rebased my tree to v4.10 (which I should not really have done ;-), but
it still doesn't apply due to "fatal: sha1 information is lacking or useless"
and "error: could not build fake ancestor". The subsequent patches also don't
apply. You may have to wait until after -rc1, rebase your patches, and
resubmit.


Sure, I'll resend after merge window. These aren't important fixes so
there is no problem in waiting for merge window to end.



Watchdog patches are in, so please feel free to resubmit at your convenience.

Thanks,
Guenter

Re: [PATCH 5/7] watchdog: s3c2410: Constify local structures

[Guenter Roeck]

On 02/24/2017 11:42 PM, Krzysztof Kozlowski wrote:

On Fri, Feb 24, 2017 at 02:05:56PM -0800, Guenter Roeck wrote:

On 02/24/2017 01:07 PM, Krzysztof Kozlowski wrote:

Structures watchdog_device, watchdog_ops and s3c2410_wdt_variant are not
modified so they can be made const to increase code safeness.

Signed-off-by: Krzysztof Kozlowski 


Conflicts with "watchdog: constify watchdog_ops structures" in my tree.
I rebased my tree to v4.10 (which I should not really have done ;-), but
it still doesn't apply due to "fatal: sha1 information is lacking or useless"
and "error: could not build fake ancestor". The subsequent patches also don't
apply. You may have to wait until after -rc1, rebase your patches, and
resubmit.


Sure, I'll resend after merge window. These aren't important fixes so
there is no problem in waiting for merge window to end.



Watchdog patches are in, so please feel free to resubmit at your convenience.

Thanks,
Guenter

[platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Fengguang Wu]

Hi Alan,

Here is another bisect result. The attached reproduce-* script may
help debug the issue.

git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git testing

commit 84c2f235ad130cf59911fdd1970d297d28540d35
Author: Alan Jenkins 
AuthorDate: Wed Feb 8 14:46:31 2017 +0100
Commit: Darren Hart 
CommitDate: Fri Feb 24 23:54:45 2017 -0800

 platform/x86: fujitsu-laptop: only register backlight device if FUJ02B1 is 
present
 
 As the backlight device registered by fujitsu-laptop relies on the
 FUJ02B1 ACPI device being present, only register the backlight device
 once that ACPI device is detected.  Drop redundant max_brightness local
 variable.  Assign current brightness before registering the backlight
 device.  Adjust indentation to make checkpatch happy.
 
 Signed-off-by: Alan Jenkins 
 [kempniu: rebase patch, rewrite commit message]
 Signed-off-by: Michał Kępień 
 Signed-off-by: Andy Shevchenko 
 Reviewed-by: Jonathan Woithe 

817d65498f  platform/x86: fujitsu-laptop: simplify acpi_bus_register_driver() 
error handling
84c2f235ad  platform/x86: fujitsu-laptop: only register backlight device if 
FUJ02B1 is present
+--+++
|  | 817d65498f | 84c2f235ad |
+--+++
| boot_successes   | 81 | 0  |
| boot_failures| 11 | 26 |
| invoked_oom-killer:gfp_mask=0x   | 7  ||
| Mem-Info | 7  ||
| Out_of_memory:Kill_process   | 7  ||
| BUG:kernel_hang_in_test_stage| 1  ||
| BUG:kernel_hang_in_boot_stage| 3  ||
| BUG:KASAN:null-ptr-deref_on_address  | 0  | 26 |
| BUG:unable_to_handle_kernel  | 0  | 26 |
| Oops | 0  | 26 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 26 |
+--+++

[   60.038293] acer_wmi: Acer Laptop ACPI-WMI Extras
[   60.039141] acer_wmi: No or unsupported WMI interface, unable to load
[   60.040390] Initializing HPQ6001 module
[   60.044011] fujitsu_laptop: call_fext_func: FUNC interface is not present
[   60.045221] 
==
[   60.046471] BUG: KASAN: null-ptr-deref on address 0008
[   60.047668] Write of size 4 by task swapper/0/1
[   60.048457] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.10.0-rc6-00053-g84c2f23 #1
[   60.049738] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.051534] Call Trace:
[   60.051975]  dump_stack+0x63/0x8d
[   60.052563]  kasan_report_error+0xdc/0x470
[   60.053272]  kasan_report+0x33/0x40
[   60.053886]  ? fujitsu_init+0x249/0x304
[   60.054560]  __asan_store4+0x6e/0x70
[   60.055245]  fujitsu_init+0x249/0x304
[   60.056025]  ? hotkey_init+0xb35/0xb35
[   60.056684]  do_one_initcall+0xf1/0x1c8
[   60.057356]  ? repair_env_string+0x2f/0x73
[   60.058065]  ? start_kernel+0x4b3/0x4b3
[   60.058854]  ? parse_args+0x3a0/0x4f0
[   60.059498]  ? do_early_param+0xb5/0xb5
[   60.060163]  kernel_init_freeable+0x1b9/0x25e
[   60.060921]  ? rest_init+0xe0/0xe0
[   60.061522]  kernel_init+0xe/0x110
[   60.062113]  ? rest_init+0xe0/0xe0
[   60.062717]  ret_from_fork+0x2c/0x40
[   60.063341] 
==
[   60.064700] Disabling lock debugging due to kernel taint
[   60.065733] BUG: unable to handle kernel NULL pointer dereference at 
0008
[   60.067077] IP: fujitsu_init+0x249/0x304
[   60.067781] PGD 0 
[   60.067783] 
[   60.068427] Oops: 0002 [#1] SMP KASAN
[   60.069065] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB   
4.10.0-rc6-00053-g84c2f23 #1
[   60.070564] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.088409] task: 882aa040 task.stack: 882b
[   60.089432] RIP: 0010:fujitsu_init+0x249/0x304
[   60.090192] RSP: :882b7e10 EFLAGS: 00010296
[   60.091107] RAX: 882aa040 RBX:  RCX: 81132406
[   60.092330] RDX: 10985844 RSI: 0003 RDI: 0286
[   60.093410] RBP: 882b7e20 R08: 0003 R09: 
[   60.094442] R10: 882b7c90 R11: 6775626564206b63 R12: 
[   60.095547] R13:  R14: 882b7eb8 R15: 
[   60.096740] FS:  

[platform/x86] 84c2f235ad BUG: KASAN: null-ptr-deref on address 0000000000000008

[Fengguang Wu]

Hi Alan,

Here is another bisect result. The attached reproduce-* script may
help debug the issue.

git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git testing

commit 84c2f235ad130cf59911fdd1970d297d28540d35
Author: Alan Jenkins 
AuthorDate: Wed Feb 8 14:46:31 2017 +0100
Commit: Darren Hart 
CommitDate: Fri Feb 24 23:54:45 2017 -0800

 platform/x86: fujitsu-laptop: only register backlight device if FUJ02B1 is 
present
 
 As the backlight device registered by fujitsu-laptop relies on the
 FUJ02B1 ACPI device being present, only register the backlight device
 once that ACPI device is detected.  Drop redundant max_brightness local
 variable.  Assign current brightness before registering the backlight
 device.  Adjust indentation to make checkpatch happy.
 
 Signed-off-by: Alan Jenkins 
 [kempniu: rebase patch, rewrite commit message]
 Signed-off-by: Michał Kępień 
 Signed-off-by: Andy Shevchenko 
 Reviewed-by: Jonathan Woithe 

817d65498f  platform/x86: fujitsu-laptop: simplify acpi_bus_register_driver() 
error handling
84c2f235ad  platform/x86: fujitsu-laptop: only register backlight device if 
FUJ02B1 is present
+--+++
|  | 817d65498f | 84c2f235ad |
+--+++
| boot_successes   | 81 | 0  |
| boot_failures| 11 | 26 |
| invoked_oom-killer:gfp_mask=0x   | 7  ||
| Mem-Info | 7  ||
| Out_of_memory:Kill_process   | 7  ||
| BUG:kernel_hang_in_test_stage| 1  ||
| BUG:kernel_hang_in_boot_stage| 3  ||
| BUG:KASAN:null-ptr-deref_on_address  | 0  | 26 |
| BUG:unable_to_handle_kernel  | 0  | 26 |
| Oops | 0  | 26 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 26 |
+--+++

[   60.038293] acer_wmi: Acer Laptop ACPI-WMI Extras
[   60.039141] acer_wmi: No or unsupported WMI interface, unable to load
[   60.040390] Initializing HPQ6001 module
[   60.044011] fujitsu_laptop: call_fext_func: FUNC interface is not present
[   60.045221] 
==
[   60.046471] BUG: KASAN: null-ptr-deref on address 0008
[   60.047668] Write of size 4 by task swapper/0/1
[   60.048457] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.10.0-rc6-00053-g84c2f23 #1
[   60.049738] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.051534] Call Trace:
[   60.051975]  dump_stack+0x63/0x8d
[   60.052563]  kasan_report_error+0xdc/0x470
[   60.053272]  kasan_report+0x33/0x40
[   60.053886]  ? fujitsu_init+0x249/0x304
[   60.054560]  __asan_store4+0x6e/0x70
[   60.055245]  fujitsu_init+0x249/0x304
[   60.056025]  ? hotkey_init+0xb35/0xb35
[   60.056684]  do_one_initcall+0xf1/0x1c8
[   60.057356]  ? repair_env_string+0x2f/0x73
[   60.058065]  ? start_kernel+0x4b3/0x4b3
[   60.058854]  ? parse_args+0x3a0/0x4f0
[   60.059498]  ? do_early_param+0xb5/0xb5
[   60.060163]  kernel_init_freeable+0x1b9/0x25e
[   60.060921]  ? rest_init+0xe0/0xe0
[   60.061522]  kernel_init+0xe/0x110
[   60.062113]  ? rest_init+0xe0/0xe0
[   60.062717]  ret_from_fork+0x2c/0x40
[   60.063341] 
==
[   60.064700] Disabling lock debugging due to kernel taint
[   60.065733] BUG: unable to handle kernel NULL pointer dereference at 
0008
[   60.067077] IP: fujitsu_init+0x249/0x304
[   60.067781] PGD 0 
[   60.067783] 
[   60.068427] Oops: 0002 [#1] SMP KASAN
[   60.069065] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB   
4.10.0-rc6-00053-g84c2f23 #1
[   60.070564] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.088409] task: 882aa040 task.stack: 882b
[   60.089432] RIP: 0010:fujitsu_init+0x249/0x304
[   60.090192] RSP: :882b7e10 EFLAGS: 00010296
[   60.091107] RAX: 882aa040 RBX:  RCX: 81132406
[   60.092330] RDX: 10985844 RSI: 0003 RDI: 0286
[   60.093410] RBP: 882b7e20 R08: 0003 R09: 
[   60.094442] R10: 882b7c90 R11: 6775626564206b63 R12: 
[   60.095547] R13:  R14: 882b7eb8 R15: 
[   60.096740] FS:  () GS:880018a0() 
knlGS:
[   60.098122] CS:  0010 DS:  ES:  CR0: 80050033
[   60.099103] CR2: 

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write
corrupts the file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2#
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2#

Thanks,
Xiong

LTP write03 writev07 xfs failures

[Xiong Zhou]

Hi,

These 2 tests PASS on Linus tree commit:
  37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux...
FAIL on commit:
  60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/...

LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h

Steps:

sh-4.2# pwd
/root/ltp
sh-4.2# git log --oneline -1
c60d3ca move_pages12: include lapi/mmap.h
sh-4.2# uname -r
4.10.0-master-60e8d3e+
sh-4.2# mount | grep test1
/dev/sda3 on /test1 type xfs
(rw,relatime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota)
sh-4.2# xfs_info /test1
meta-data=/dev/sda3  isize=512agcount=16, agsize=245696 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1 spinodes=0
data =   bsize=4096   blocks=3931136, imaxpct=25
 =   sunit=64 swidth=64 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=64 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/write/write03
write03 0  TINFO  :  Enter Block 1: test to check if write
corrupts the file when write fails
write03 1  TFAIL  :  write03.c:125: failure of write(2) corrupted the file
write03 0  TINFO  :  Exit block 1
sh-4.2#
sh-4.2# TMPDIR=/test1 ./testcases/kernel/syscalls/writev/writev07
tst_test.c:760: INFO: Timeout per run is 0h 05m 00s
writev07.c:60: INFO: starting test with initial file offset: 0
writev07.c:82: INFO: got EFAULT
writev07.c:87: FAIL: file was written to
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 65
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4096
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged
writev07.c:60: INFO: starting test with initial file offset: 4097
writev07.c:82: INFO: got EFAULT
writev07.c:89: PASS: file stayed untouched
writev07.c:93: PASS: offset stayed unchanged

Summary:
passed   7
failed   1
skipped  0
warnings 0
sh-4.2#
sh-4.2# mkfs.xfs -V
mkfs.xfs version 4.7.0
sh-4.2# cd ../xfsprogs/
sh-4.2# git log --oneline -1
d7e1f5f xfsprogs: Release v4.7
sh-4.2#

Thanks,
Xiong

Re: [PATCH v3 0/2] perf/sdt: Directly record SDT events with 'perf record'

[Ravi Bangoria]

Looks like I've older address of Masami(masami.hiramatsu...@hitachi.com) in my 
database.

Adding  To: mhira...@kernel.org

-Ravi

On Friday 24 February 2017 01:13 PM, Ravi Bangoria wrote:
> All events from 'perf list', except SDT events, can be directly recorded
> with 'perf record'. But, the flow is little different for SDT events.
> Probe point for SDT event needs to be created using 'perf probe' before
> recording it using 'perf record'.
>

Re: [PATCH v3 0/2] perf/sdt: Directly record SDT events with 'perf record'

[Ravi Bangoria]

Looks like I've older address of Masami(masami.hiramatsu...@hitachi.com) in my 
database.

Adding  To: mhira...@kernel.org

-Ravi

On Friday 24 February 2017 01:13 PM, Ravi Bangoria wrote:
> All events from 'perf list', except SDT events, can be directly recorded
> with 'perf record'. But, the flow is little different for SDT events.
> Probe point for SDT event needs to be created using 'perf probe' before
> recording it using 'perf record'.
>

Re: Recommended notation for OPP to avoid DTC warnings

[Viresh Kumar]

On 26-02-17, 14:18, Masahiro Yamada wrote:
> Hi.
> 
> 
> Decumentation/devicetree/bindings/opp/opp.txt
> takes examples like this:
> 
> opp@10 {
> opp-hz = /bits/ 64 <10>;
> opp-microvolt = <97 975000 985000>;
> opp-microamp = <7>;
> clock-latency-ns = <30>;
> opp-suspend;
> };
> opp@11 {
> opp-hz = /bits/ 64 <11>;
> opp-microvolt = <98 100 101>;
> opp-microamp = <8>;
> clock-latency-ns = <31>;
> };
> opp@12 {
> opp-hz = /bits/ 64 <12>;
> opp-microvolt = <1025000>;
> clock-latency-ns = <29>;
> turbo-mode;
> };
> 
> 
> If we follow this notation and the device-tree is built with W=1,
> DTC warns like follows:
> 
> 
> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> unit name, but no reg property
> 
> 
> Is there a recommended notation to avoid it?
> 
> Maybe, simply omit the "@" ?

I would let Rob suggest something here.

-- 
viresh

Re: Recommended notation for OPP to avoid DTC warnings

[Viresh Kumar]

On 26-02-17, 14:18, Masahiro Yamada wrote:
> Hi.
> 
> 
> Decumentation/devicetree/bindings/opp/opp.txt
> takes examples like this:
> 
> opp@10 {
> opp-hz = /bits/ 64 <10>;
> opp-microvolt = <97 975000 985000>;
> opp-microamp = <7>;
> clock-latency-ns = <30>;
> opp-suspend;
> };
> opp@11 {
> opp-hz = /bits/ 64 <11>;
> opp-microvolt = <98 100 101>;
> opp-microamp = <8>;
> clock-latency-ns = <31>;
> };
> opp@12 {
> opp-hz = /bits/ 64 <12>;
> opp-microvolt = <1025000>;
> clock-latency-ns = <29>;
> turbo-mode;
> };
> 
> 
> If we follow this notation and the device-tree is built with W=1,
> DTC warns like follows:
> 
> 
> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> unit name, but no reg property
> 
> 
> Is there a recommended notation to avoid it?
> 
> Maybe, simply omit the "@" ?

I would let Rob suggest something here.

-- 
viresh

Re: watchdog: softdog: fire watchdog even if softirqs do not get to run

[Guenter Roeck]

On Fri, Feb 17, 2017 at 07:25:02PM +0100, Niklas Cassel wrote:
> From: Niklas Cassel 
> 
> Checking for timer expiration is done from the softirq TIMER_SOFTIRQ.
> 
> Since commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job"),
> pending softirqs are no longer always handled immediately, instead,
> if there are pending softirqs, and ksoftirqd is in state TASK_RUNNING,
> the handling of the softirqs are deferred, and are instead supposed
> to be handled by ksoftirqd, when ksoftirqd gets scheduled.
> 
> If a user space process with a real-time policy starts to misbehave
> by never relinquishing the CPU while ksoftirqd is in state TASK_RUNNING,
> what will happen is that all softirqs will get deferred, while ksoftirqd,
> which is supposed to handle the deferred softirqs, will never get to run.
> 
> To make sure that the watchdog is able to fire even when we do not get
> to run softirqs, replace the timers with hrtimers.
> 
> Signed-off-by: Niklas Cassel 
> Reviewed-by: Guenter Roeck 

Niklas,

Please rebase onto current mainline, test, and resubmit.

Thanks,
Guenter

> ---
>  drivers/watchdog/softdog.c | 40 
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/watchdog/softdog.c b/drivers/watchdog/softdog.c
> index c7bdc986dca1..0f67cd068465 100644
> --- a/drivers/watchdog/softdog.c
> +++ b/drivers/watchdog/softdog.c
> @@ -21,13 +21,12 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -54,7 +53,10 @@ module_param(soft_panic, int, 0);
>  MODULE_PARM_DESC(soft_panic,
>   "Softdog action, set to 1 to panic, 0 to reboot (default=0)");
>  
> -static void softdog_fire(unsigned long data)
> +static struct hrtimer softdog_ticktock;
> +static struct hrtimer softdog_preticktock;
> +
> +static enum hrtimer_restart softdog_fire(struct hrtimer *timer)
>  {
>   module_put(THIS_MODULE);
>   if (soft_noboot) {
> @@ -67,41 +69,42 @@ static void softdog_fire(unsigned long data)
>   emergency_restart();
>   pr_crit("Reboot didn't ?\n");
>   }
> -}
>  
> -static struct timer_list softdog_ticktock =
> - TIMER_INITIALIZER(softdog_fire, 0, 0);
> + return HRTIMER_NORESTART;
> +}
>  
>  static struct watchdog_device softdog_dev;
>  
> -static void softdog_pretimeout(unsigned long data)
> +static enum hrtimer_restart softdog_pretimeout(struct hrtimer *timer)
>  {
>   watchdog_notify_pretimeout(_dev);
> -}
>  
> -static struct timer_list softdog_preticktock =
> - TIMER_INITIALIZER(softdog_pretimeout, 0, 0);
> + return HRTIMER_NORESTART;
> +}
>  
>  static int softdog_ping(struct watchdog_device *w)
>  {
> - if (!mod_timer(_ticktock, jiffies + (w->timeout * HZ)))
> + if (!hrtimer_active(_ticktock))
>   __module_get(THIS_MODULE);
> + hrtimer_start(_ticktock, ktime_set(w->timeout, 0),
> +   HRTIMER_MODE_REL);
>  
>   if (w->pretimeout)
> - mod_timer(_preticktock, jiffies +
> -   (w->timeout - w->pretimeout) * HZ);
> + hrtimer_start(_preticktock,
> +   ktime_set(w->timeout - w->pretimeout, 0),
> +   HRTIMER_MODE_REL);
>   else
> - del_timer(_preticktock);
> + hrtimer_cancel(_preticktock);
>  
>   return 0;
>  }
>  
>  static int softdog_stop(struct watchdog_device *w)
>  {
> - if (del_timer(_ticktock))
> + if (hrtimer_cancel(_ticktock))
>   module_put(THIS_MODULE);
>  
> - del_timer(_preticktock);
> + hrtimer_cancel(_preticktock);
>  
>   return 0;
>  }
> @@ -134,6 +137,11 @@ static int __init softdog_init(void)
>   watchdog_set_nowayout(_dev, nowayout);
>   watchdog_stop_on_reboot(_dev);
>  
> + hrtimer_init(_ticktock, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + softdog_ticktock.function = softdog_fire;
> + hrtimer_init(_preticktock, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + softdog_preticktock.function = softdog_pretimeout;
> +
>   ret = watchdog_register_device(_dev);
>   if (ret)
>   return ret;

Re: watchdog: softdog: fire watchdog even if softirqs do not get to run

[Guenter Roeck]

On Fri, Feb 17, 2017 at 07:25:02PM +0100, Niklas Cassel wrote:
> From: Niklas Cassel 
> 
> Checking for timer expiration is done from the softirq TIMER_SOFTIRQ.
> 
> Since commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job"),
> pending softirqs are no longer always handled immediately, instead,
> if there are pending softirqs, and ksoftirqd is in state TASK_RUNNING,
> the handling of the softirqs are deferred, and are instead supposed
> to be handled by ksoftirqd, when ksoftirqd gets scheduled.
> 
> If a user space process with a real-time policy starts to misbehave
> by never relinquishing the CPU while ksoftirqd is in state TASK_RUNNING,
> what will happen is that all softirqs will get deferred, while ksoftirqd,
> which is supposed to handle the deferred softirqs, will never get to run.
> 
> To make sure that the watchdog is able to fire even when we do not get
> to run softirqs, replace the timers with hrtimers.
> 
> Signed-off-by: Niklas Cassel 
> Reviewed-by: Guenter Roeck 

Niklas,

Please rebase onto current mainline, test, and resubmit.

Thanks,
Guenter

> ---
>  drivers/watchdog/softdog.c | 40 
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/watchdog/softdog.c b/drivers/watchdog/softdog.c
> index c7bdc986dca1..0f67cd068465 100644
> --- a/drivers/watchdog/softdog.c
> +++ b/drivers/watchdog/softdog.c
> @@ -21,13 +21,12 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -54,7 +53,10 @@ module_param(soft_panic, int, 0);
>  MODULE_PARM_DESC(soft_panic,
>   "Softdog action, set to 1 to panic, 0 to reboot (default=0)");
>  
> -static void softdog_fire(unsigned long data)
> +static struct hrtimer softdog_ticktock;
> +static struct hrtimer softdog_preticktock;
> +
> +static enum hrtimer_restart softdog_fire(struct hrtimer *timer)
>  {
>   module_put(THIS_MODULE);
>   if (soft_noboot) {
> @@ -67,41 +69,42 @@ static void softdog_fire(unsigned long data)
>   emergency_restart();
>   pr_crit("Reboot didn't ?\n");
>   }
> -}
>  
> -static struct timer_list softdog_ticktock =
> - TIMER_INITIALIZER(softdog_fire, 0, 0);
> + return HRTIMER_NORESTART;
> +}
>  
>  static struct watchdog_device softdog_dev;
>  
> -static void softdog_pretimeout(unsigned long data)
> +static enum hrtimer_restart softdog_pretimeout(struct hrtimer *timer)
>  {
>   watchdog_notify_pretimeout(_dev);
> -}
>  
> -static struct timer_list softdog_preticktock =
> - TIMER_INITIALIZER(softdog_pretimeout, 0, 0);
> + return HRTIMER_NORESTART;
> +}
>  
>  static int softdog_ping(struct watchdog_device *w)
>  {
> - if (!mod_timer(_ticktock, jiffies + (w->timeout * HZ)))
> + if (!hrtimer_active(_ticktock))
>   __module_get(THIS_MODULE);
> + hrtimer_start(_ticktock, ktime_set(w->timeout, 0),
> +   HRTIMER_MODE_REL);
>  
>   if (w->pretimeout)
> - mod_timer(_preticktock, jiffies +
> -   (w->timeout - w->pretimeout) * HZ);
> + hrtimer_start(_preticktock,
> +   ktime_set(w->timeout - w->pretimeout, 0),
> +   HRTIMER_MODE_REL);
>   else
> - del_timer(_preticktock);
> + hrtimer_cancel(_preticktock);
>  
>   return 0;
>  }
>  
>  static int softdog_stop(struct watchdog_device *w)
>  {
> - if (del_timer(_ticktock))
> + if (hrtimer_cancel(_ticktock))
>   module_put(THIS_MODULE);
>  
> - del_timer(_preticktock);
> + hrtimer_cancel(_preticktock);
>  
>   return 0;
>  }
> @@ -134,6 +137,11 @@ static int __init softdog_init(void)
>   watchdog_set_nowayout(_dev, nowayout);
>   watchdog_stop_on_reboot(_dev);
>  
> + hrtimer_init(_ticktock, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + softdog_ticktock.function = softdog_fire;
> + hrtimer_init(_preticktock, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + softdog_preticktock.function = softdog_pretimeout;
> +
>   ret = watchdog_register_device(_dev);
>   if (ret)
>   return ret;

Re: [PATCH RFC] arm64/mm: handle memmap kernel option

[Yisheng Xie]

Hi Ard,

Thanks for comment.
On 2017/2/26 18:46, Ard Biesheuvel wrote:
> On 25 February 2017 at 06:47, Yisheng Xie  wrote:
>> When use device tree mode, user can reserve memory by changes the dts,
>> however, when boot with ACPI, user cannot reserve memory except by
>> changing the ACPI table in BIOS, which is not so convenient.
>>
>> To make user reserve memory for some specific use more convenient,
>> this patch implement the following memmap variants:
>>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
>>
>> Reported-by: Bob Dong 
>> Signed-off-by: Yisheng Xie 
> 
> Could you explain which problem you are solving here? ACPI implies
> UEFI on arm64, and so these reservations could be made by a boot
> component instead, if it requires a fixed memory reservation. If this
> is a reservation for, e.g., OP-TEE, we should not rely on the command
> line to communicate this information.
> 
We just want to reserve some memory for a driver and I just not so familiar
with how to reserve memory with UEFI. So doubt about whether it is suitable
to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
for a long time.

Thanks
Yisheng Xie

Re: [PATCH RFC] arm64/mm: handle memmap kernel option

[Yisheng Xie]

Hi Ard,

Thanks for comment.
On 2017/2/26 18:46, Ard Biesheuvel wrote:
> On 25 February 2017 at 06:47, Yisheng Xie  wrote:
>> When use device tree mode, user can reserve memory by changes the dts,
>> however, when boot with ACPI, user cannot reserve memory except by
>> changing the ACPI table in BIOS, which is not so convenient.
>>
>> To make user reserve memory for some specific use more convenient,
>> this patch implement the following memmap variants:
>>  - memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
>>  - memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
>>
>> Reported-by: Bob Dong 
>> Signed-off-by: Yisheng Xie 
> 
> Could you explain which problem you are solving here? ACPI implies
> UEFI on arm64, and so these reservations could be made by a boot
> component instead, if it requires a fixed memory reservation. If this
> is a reservation for, e.g., OP-TEE, we should not rely on the command
> line to communicate this information.
> 
We just want to reserve some memory for a driver and I just not so familiar
with how to reserve memory with UEFI. So doubt about whether it is suitable
to reserve memory with cmdline like "memmap=xxx", which had appeared in x86
for a long time.

Thanks
Yisheng Xie

Re: [PATCH v2 1/2] extcon: int3496: Rename GPIO pins in accordance with binding

[Chanwoo Choi]

Hi,

On 2017년 02월 24일 21:35, Andy Shevchenko wrote:
> Update GPIO pin names in extcon-intel-int3496.c driver to follow
> the existing extcon binding.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/extcon/extcon-intel-int3496.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-intel-int3496.c 
> b/drivers/extcon/extcon-intel-int3496.c
> index 38eb6cab938f..81713bf7487e 100644
> --- a/drivers/extcon/extcon-intel-int3496.c
> +++ b/drivers/extcon/extcon-intel-int3496.c
> @@ -105,13 +105,13 @@ static int int3496_probe(struct platform_device *pdev)
>   return data->usb_id_irq;
>   }
>  
> - data->gpio_vbus_en = devm_gpiod_get_index(dev, "vbus en",
> + data->gpio_vbus_en = devm_gpiod_get_index(dev, "vbus",
>INT3496_GPIO_VBUS_EN,
>GPIOD_ASIS);
>   if (IS_ERR(data->gpio_vbus_en))
>   dev_info(dev, "can't request VBUS EN GPIO\n");
>  
> - data->gpio_usb_mux = devm_gpiod_get_index(dev, "usb mux",
> + data->gpio_usb_mux = devm_gpiod_get_index(dev, "mux",
>INT3496_GPIO_USB_MUX,
>GPIOD_ASIS);
>   if (IS_ERR(data->gpio_usb_mux))
> 

Applied them(patch1/2). Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2 1/2] extcon: int3496: Rename GPIO pins in accordance with binding

[Chanwoo Choi]

Hi,

On 2017년 02월 24일 21:35, Andy Shevchenko wrote:
> Update GPIO pin names in extcon-intel-int3496.c driver to follow
> the existing extcon binding.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/extcon/extcon-intel-int3496.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-intel-int3496.c 
> b/drivers/extcon/extcon-intel-int3496.c
> index 38eb6cab938f..81713bf7487e 100644
> --- a/drivers/extcon/extcon-intel-int3496.c
> +++ b/drivers/extcon/extcon-intel-int3496.c
> @@ -105,13 +105,13 @@ static int int3496_probe(struct platform_device *pdev)
>   return data->usb_id_irq;
>   }
>  
> - data->gpio_vbus_en = devm_gpiod_get_index(dev, "vbus en",
> + data->gpio_vbus_en = devm_gpiod_get_index(dev, "vbus",
>INT3496_GPIO_VBUS_EN,
>GPIOD_ASIS);
>   if (IS_ERR(data->gpio_vbus_en))
>   dev_info(dev, "can't request VBUS EN GPIO\n");
>  
> - data->gpio_usb_mux = devm_gpiod_get_index(dev, "usb mux",
> + data->gpio_usb_mux = devm_gpiod_get_index(dev, "mux",
>INT3496_GPIO_USB_MUX,
>GPIOD_ASIS);
>   if (IS_ERR(data->gpio_usb_mux))
> 

Applied them(patch1/2). Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

linux-next: Tree for Feb 27

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v4.12 to your linux-next
included branches until after v4.11-rc1 has been released.

Changes since 20170224:

The vfs tree gained conflicts agains Linus' and the f2fs trees and a
build failure for which I added a fix patch.

The drm tree lost its build failure.

The scsi tree still has its build failure, so I used the version from
next-20170222.

Non-merge commits (relative to Linus' tree): 1015
 1469 files changed, 61706 insertions(+), 22830 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 253 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c4f3f22eddc9 Merge tag 'linux-kselftest-4.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest)
Merging fixes/master (c470abd4fde4 Linux 4.10)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 
64-bit get_user())
Merging m68k-current/for-linus (3dfe33020ca8 m68k/sun3: Remove dead code in 
paging_init())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix 
under a hypervisor)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (47d3a07528ec net/mlx4_en: fix overflow in 
mlx4_en_init_timestamp())
Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below 
IPV6_MIN_MTU.)
Merging netfilter/master (47b1f6fd6ebc uapi: stop including linux/sysctl.h in 
uapi/linux/netfilter.h)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (8a96bb837818 mac80211: don't reorder frames with SN 
smaller than SSN)
Merging sound-current/for-linus (44b46d739d35 ALSA: hda - Add Geminilake PCI ID)
Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore 
pcie_pme_driver.remove)
Merging driver-core.current/driver-core-linus (bc49a7831b11 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (bc49a7831b11 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (bc49a7831b11 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (6cf1bf636a06 staging: vchiq_2835_arm: 
Make cache-line-size a required DT property)
Merging char-misc.current/char-misc-linus (bc49a7831b11 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (6e11617fcff3 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (12cb3a1c4184 

linux-next: Tree for Feb 27

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v4.12 to your linux-next
included branches until after v4.11-rc1 has been released.

Changes since 20170224:

The vfs tree gained conflicts agains Linus' and the f2fs trees and a
build failure for which I added a fix patch.

The drm tree lost its build failure.

The scsi tree still has its build failure, so I used the version from
next-20170222.

Non-merge commits (relative to Linus' tree): 1015
 1469 files changed, 61706 insertions(+), 22830 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 253 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c4f3f22eddc9 Merge tag 'linux-kselftest-4.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest)
Merging fixes/master (c470abd4fde4 Linux 4.10)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 
64-bit get_user())
Merging m68k-current/for-linus (3dfe33020ca8 m68k/sun3: Remove dead code in 
paging_init())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix 
under a hypervisor)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (47d3a07528ec net/mlx4_en: fix overflow in 
mlx4_en_init_timestamp())
Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below 
IPV6_MIN_MTU.)
Merging netfilter/master (47b1f6fd6ebc uapi: stop including linux/sysctl.h in 
uapi/linux/netfilter.h)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (8a96bb837818 mac80211: don't reorder frames with SN 
smaller than SSN)
Merging sound-current/for-linus (44b46d739d35 ALSA: hda - Add Geminilake PCI ID)
Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore 
pcie_pme_driver.remove)
Merging driver-core.current/driver-core-linus (bc49a7831b11 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (bc49a7831b11 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (bc49a7831b11 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (6cf1bf636a06 staging: vchiq_2835_arm: 
Make cache-line-size a required DT property)
Merging char-misc.current/char-misc-linus (bc49a7831b11 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (6e11617fcff3 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (12cb3a1c4184 

Re: [PATCH v4 00/23] drm/rockchip: MIPI fixes & improvements

[Chris Zhong]

Hi John

I have test this v4 series on my RK3399 board, it works well, thanks.

Tested-by: Chris Zhong


On 02/24/2017 08:54 PM, John Keeping wrote:

This version is mostly small changes in response to review comments from
Sean and Chris, the details are in the individual patches.

I decided to drop the final patch which adds support for MIPI read
commands because I'm not using that feature now and I can't easily test
it.  It's on the list if anyone wants to pick it up in the future.

Version 3 was posted here:
http://www.spinics.net/lists/dri-devel/msg130977.html

Thanks to Sean Paul and Chris Zhong for their review and testing of this
series.

John Keeping (23):
   drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
 MIPI
   drm/rockchip: dw-mipi-dsi: pass mode in where needed
   drm/rockchip: dw-mipi-dsi: remove mode_set hook
   drm/rockchip: dw-mipi-dsi: fix command header writes
   drm/rockchip: dw-mipi-dsi: fix generic packet status check
   drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
   drm/rockchip: dw-mipi-dsi: include bad value in error message
   drm/rockchip: dw-mipi-dsi: respect message flags
   drm/rockchip: dw-mipi-dsi: only request HS clock when required
   drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
   drm/rockchip: dw-mipi-dsi: prepare panel after phy init
   drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
   drm/rockchip: dw-mipi-dsi: fix escape clock rate
   drm/rockchip: dw-mipi-dsi: ensure PHY is reset
   drm/rockchip: dw-mipi-dsi: configure PHY before enabling
   drm/rockchip: dw-mipi-dsi: properly configure PHY timing
   drm/rockchip: dw-mipi-dsi: improve PLL configuration
   drm/rockchip: dw-mipi-dsi: use specific poll helper
   drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
   drm/rockchip: vop: test for P{H,V}SYNC
   drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
   drm/rockchip: dw-mipi-dsi: support non-burst modes
   drm/rockchip: dw-mipi-dsi: add reset control

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 325 +++-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
  2 files changed, 220 insertions(+), 109 deletions(-)



--
Chris Zhong

Re: [PATCH v4 00/23] drm/rockchip: MIPI fixes & improvements

[Chris Zhong]

Hi John

I have test this v4 series on my RK3399 board, it works well, thanks.

Tested-by: Chris Zhong


On 02/24/2017 08:54 PM, John Keeping wrote:

This version is mostly small changes in response to review comments from
Sean and Chris, the details are in the individual patches.

I decided to drop the final patch which adds support for MIPI read
commands because I'm not using that feature now and I can't easily test
it.  It's on the list if anyone wants to pick it up in the future.

Version 3 was posted here:
http://www.spinics.net/lists/dri-devel/msg130977.html

Thanks to Sean Paul and Chris Zhong for their review and testing of this
series.

John Keeping (23):
   drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
 MIPI
   drm/rockchip: dw-mipi-dsi: pass mode in where needed
   drm/rockchip: dw-mipi-dsi: remove mode_set hook
   drm/rockchip: dw-mipi-dsi: fix command header writes
   drm/rockchip: dw-mipi-dsi: fix generic packet status check
   drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
   drm/rockchip: dw-mipi-dsi: include bad value in error message
   drm/rockchip: dw-mipi-dsi: respect message flags
   drm/rockchip: dw-mipi-dsi: only request HS clock when required
   drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
   drm/rockchip: dw-mipi-dsi: prepare panel after phy init
   drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
   drm/rockchip: dw-mipi-dsi: fix escape clock rate
   drm/rockchip: dw-mipi-dsi: ensure PHY is reset
   drm/rockchip: dw-mipi-dsi: configure PHY before enabling
   drm/rockchip: dw-mipi-dsi: properly configure PHY timing
   drm/rockchip: dw-mipi-dsi: improve PLL configuration
   drm/rockchip: dw-mipi-dsi: use specific poll helper
   drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
   drm/rockchip: vop: test for P{H,V}SYNC
   drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
   drm/rockchip: dw-mipi-dsi: support non-burst modes
   drm/rockchip: dw-mipi-dsi: add reset control

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 325 +++-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
  2 files changed, 220 insertions(+), 109 deletions(-)



--
Chris Zhong

Re: [PATCH 2/2] media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

[pankaj.dubey]

Hello Javier,

On Saturday 25 February 2017 01:12 AM, Javier Martinez Canillas wrote:
> Hello Pankaj,
> 
> On 12/16/2016 08:48 AM, Pankaj Dubey wrote:
>> From: Smitha T Murthy 
>>
>> It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
>> and we try to use reserved memory for MFC, reqbufs fails with below
>> mentioned error
>> ---
>> V4L2 Codec decoding example application
>> Kamil Debski 
>> Copyright 2012 Samsung Electronics Co., Ltd.
>>
>> Opening MFC.
>> (mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
>> bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
>> 42.339165] Remapping memory failed, error: -6
>>
>> MFC Open Success.
>> (main.c:main:711): Successfully opened all necessary files and devices
>> (mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
>> size=4194304 (requested=4194304)
>> (mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
>> (requested 2)
>>
>> [App] Out buf phy : 0x, virt : 0x
>> Output Length is = 0x30
>> Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
>> -
>> This is because the device requesting for memory is mfc0.left not the parent 
>> mfc0.
>> Hence setting of alloc_devs need to be done only if IOMMU is enabled
>> and in that case both the left and right device is treated as mfc0 only.
>>
> 
> I see, so likely you were facing the issue described in patch 1/2 after this
> patch since the driver doesn't set alloc_devs when IOMMU is disabled, right?
> 

Yes.

> In any case, I guess these patches have been superseded by Marek's series[0]
> so they are no longer needed?
> 

Yes, these patches have been superseded but now by Marek's series.
I missed to check Marek's series [0] due to some official assignment,
but we followed up our patch series with Marek, and fix was provided in
of_reserved_mem.c via patch [1] which has been accepted and merged as
well. I will try to find out some time and test Marek's patch series [0].

[1]: https://patchwork.kernel.org/patch/9482499/

Thanks,
Pankaj Dubey

> [0]: https://www.spinics.net/lists/linux-media/msg56.html
> 
> Best regards,
> 

Re: [PATCH 2/2] media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

[pankaj.dubey]

Hello Javier,

On Saturday 25 February 2017 01:12 AM, Javier Martinez Canillas wrote:
> Hello Pankaj,
> 
> On 12/16/2016 08:48 AM, Pankaj Dubey wrote:
>> From: Smitha T Murthy 
>>
>> It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
>> and we try to use reserved memory for MFC, reqbufs fails with below
>> mentioned error
>> ---
>> V4L2 Codec decoding example application
>> Kamil Debski 
>> Copyright 2012 Samsung Electronics Co., Ltd.
>>
>> Opening MFC.
>> (mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
>> bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
>> 42.339165] Remapping memory failed, error: -6
>>
>> MFC Open Success.
>> (main.c:main:711): Successfully opened all necessary files and devices
>> (mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
>> size=4194304 (requested=4194304)
>> (mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
>> (requested 2)
>>
>> [App] Out buf phy : 0x, virt : 0x
>> Output Length is = 0x30
>> Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
>> -
>> This is because the device requesting for memory is mfc0.left not the parent 
>> mfc0.
>> Hence setting of alloc_devs need to be done only if IOMMU is enabled
>> and in that case both the left and right device is treated as mfc0 only.
>>
> 
> I see, so likely you were facing the issue described in patch 1/2 after this
> patch since the driver doesn't set alloc_devs when IOMMU is disabled, right?
> 

Yes.

> In any case, I guess these patches have been superseded by Marek's series[0]
> so they are no longer needed?
> 

Yes, these patches have been superseded but now by Marek's series.
I missed to check Marek's series [0] due to some official assignment,
but we followed up our patch series with Marek, and fix was provided in
of_reserved_mem.c via patch [1] which has been accepted and merged as
well. I will try to find out some time and test Marek's patch series [0].

[1]: https://patchwork.kernel.org/patch/9482499/

Thanks,
Pankaj Dubey

> [0]: https://www.spinics.net/lists/linux-media/msg56.html
> 
> Best regards,
> 

Re: [PATCH net] rxrpc: Kernel calls get stuck in recvmsg

[David Miller]

From: David Howells 
Date: Fri, 24 Feb 2017 21:57:13 +

> Calls made through the in-kernel interface can end up getting stuck because
> of a missed variable update in a loop in rxrpc_recvmsg_data().  The problem
> is like this:
> 
>  (1) A new packet comes in and doesn't cause a notification to be given to
>  the client as there's still another packet in the ring - the
>  assumption being that if the client will keep drawing off data until
>  the ring is empty.
> 
>  (2) The client is in rxrpc_recvmsg_data(), inside the big while loop that
>  iterates through the packets.  This copies the window pointers into
>  variables rather than using the information in the call struct
>  because:
> 
>  (a) MSG_PEEK might be in effect;
> 
>  (b) we need a barrier after reading call->rx_top to pair with the
>barrier in the softirq routine that loads the buffer.
> 
>  (3) The reading of call->rx_top is done outside of the loop, and top is
>  never updated whilst we're in the loop.  This means that even through
>  there's a new packet available, we don't see it and may return -EFAULT
>  to the caller - who will happily return to the scheduler and await the
>  next notification.
> 
>  (4) No further notifications are forthcoming until there's an abort as the
>  ring isn't empty.
> 
> The fix is to move the read of call->rx_top inside the loop - but it needs
> to be done before the condition is checked.
> 
> Reported-by: Marc Dionne 
> Signed-off-by: David Howells 
> Tested-by: Marc Dionne 

Applied, thanks.

Re: [PATCH net] rxrpc: Kernel calls get stuck in recvmsg

[David Miller]

From: David Howells 
Date: Fri, 24 Feb 2017 21:57:13 +

> Calls made through the in-kernel interface can end up getting stuck because
> of a missed variable update in a loop in rxrpc_recvmsg_data().  The problem
> is like this:
> 
>  (1) A new packet comes in and doesn't cause a notification to be given to
>  the client as there's still another packet in the ring - the
>  assumption being that if the client will keep drawing off data until
>  the ring is empty.
> 
>  (2) The client is in rxrpc_recvmsg_data(), inside the big while loop that
>  iterates through the packets.  This copies the window pointers into
>  variables rather than using the information in the call struct
>  because:
> 
>  (a) MSG_PEEK might be in effect;
> 
>  (b) we need a barrier after reading call->rx_top to pair with the
>barrier in the softirq routine that loads the buffer.
> 
>  (3) The reading of call->rx_top is done outside of the loop, and top is
>  never updated whilst we're in the loop.  This means that even through
>  there's a new packet available, we don't see it and may return -EFAULT
>  to the caller - who will happily return to the scheduler and await the
>  next notification.
> 
>  (4) No further notifications are forthcoming until there's an abort as the
>  ring isn't empty.
> 
> The fix is to move the read of call->rx_top inside the loop - but it needs
> to be done before the condition is checked.
> 
> Reported-by: Marc Dionne 
> Signed-off-by: David Howells 
> Tested-by: Marc Dionne 

Applied, thanks.

Re: [PATCH V2] f2fs: introduce free nid bitmap

[Chao Yu]

On 2017/2/26 3:02, Jaegeuk Kim wrote:
> On 02/25, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> I added below diff code into this patch in order to fix incorrectly nid 
>> status
>> updating to reduce large latency of generic/251 in fstest, could you help to
>> review code below?
> 
> Understand the problem, and how about this?
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 52db02396878..83b305689913 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1765,7 +1765,7 @@ static void __remove_nid_from_list(struct f2fs_sb_info 
> *sbi,
>   radix_tree_delete(_i->free_nid_root, i->nid);
>  }
>  
> -static int add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
> +static bool add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
>  {
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   struct free_nid *i;
> @@ -1774,14 +1774,14 @@ static int add_free_nid(struct f2fs_sb_info *sbi, 
> nid_t nid, bool build)
>  
>   /* 0 nid should not be used */
>   if (unlikely(nid == 0))
> - return 0;
> + return false;
>  
>   if (build) {
>   /* do not add allocated nids */
>   ne = __lookup_nat_cache(nm_i, nid);
>   if (ne && (!get_nat_flag(ne, IS_CHECKPOINTED) ||
>   nat_get_blkaddr(ne) != NULL_ADDR))
> - return 0;
> + return false;
>   }
>  
>   i = f2fs_kmem_cache_alloc(free_nid_slab, GFP_NOFS);
> @@ -1790,7 +1790,7 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
> nid, bool build)
>  
>   if (radix_tree_preload(GFP_NOFS)) {
>   kmem_cache_free(free_nid_slab, i);
> - return 0;
> + return false;

If there is no memory, actually current free nid is still available, we need to
return true (or other value -1?), then caller can set free_nid_bitmap correctly.

>   }
>  
>   spin_lock(_i->nid_list_lock);
> @@ -1799,9 +1799,9 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
> nid, bool build)
>   radix_tree_preload_end();
>   if (err) {
>   kmem_cache_free(free_nid_slab, i);
> - return 0;
> + return false;

ditto.

Thanks,

>   }
> - return 1;
> + return true;
>  }
>  
>  static void remove_free_nid(struct f2fs_sb_info *sbi, nid_t nid)
> @@ -1851,6 +1851,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
>   i = start_nid % NAT_ENTRY_PER_BLOCK;
>  
>   for (; i < NAT_ENTRY_PER_BLOCK; i++, start_nid++) {
> + bool freed = false;
>  
>   if (unlikely(start_nid >= nm_i->max_nid))
>   break;
> @@ -1858,8 +1859,8 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
>   blk_addr = le32_to_cpu(nat_blk->entries[i].block_addr);
>   f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
>   if (blk_addr == NULL_ADDR)
> - add_free_nid(sbi, start_nid, true);
> - update_free_nid_bitmap(sbi, start_nid, blk_addr == NULL_ADDR);
> + freed = add_free_nid(sbi, start_nid, true);
> + update_free_nid_bitmap(sbi, start_nid, freed);
>   }
>  }
>  
> 

Re: [PATCH V2] f2fs: introduce free nid bitmap

[Chao Yu]

On 2017/2/26 3:02, Jaegeuk Kim wrote:
> On 02/25, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> I added below diff code into this patch in order to fix incorrectly nid 
>> status
>> updating to reduce large latency of generic/251 in fstest, could you help to
>> review code below?
> 
> Understand the problem, and how about this?
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 52db02396878..83b305689913 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1765,7 +1765,7 @@ static void __remove_nid_from_list(struct f2fs_sb_info 
> *sbi,
>   radix_tree_delete(_i->free_nid_root, i->nid);
>  }
>  
> -static int add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
> +static bool add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
>  {
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   struct free_nid *i;
> @@ -1774,14 +1774,14 @@ static int add_free_nid(struct f2fs_sb_info *sbi, 
> nid_t nid, bool build)
>  
>   /* 0 nid should not be used */
>   if (unlikely(nid == 0))
> - return 0;
> + return false;
>  
>   if (build) {
>   /* do not add allocated nids */
>   ne = __lookup_nat_cache(nm_i, nid);
>   if (ne && (!get_nat_flag(ne, IS_CHECKPOINTED) ||
>   nat_get_blkaddr(ne) != NULL_ADDR))
> - return 0;
> + return false;
>   }
>  
>   i = f2fs_kmem_cache_alloc(free_nid_slab, GFP_NOFS);
> @@ -1790,7 +1790,7 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
> nid, bool build)
>  
>   if (radix_tree_preload(GFP_NOFS)) {
>   kmem_cache_free(free_nid_slab, i);
> - return 0;
> + return false;

If there is no memory, actually current free nid is still available, we need to
return true (or other value -1?), then caller can set free_nid_bitmap correctly.

>   }
>  
>   spin_lock(_i->nid_list_lock);
> @@ -1799,9 +1799,9 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
> nid, bool build)
>   radix_tree_preload_end();
>   if (err) {
>   kmem_cache_free(free_nid_slab, i);
> - return 0;
> + return false;

ditto.

Thanks,

>   }
> - return 1;
> + return true;
>  }
>  
>  static void remove_free_nid(struct f2fs_sb_info *sbi, nid_t nid)
> @@ -1851,6 +1851,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
>   i = start_nid % NAT_ENTRY_PER_BLOCK;
>  
>   for (; i < NAT_ENTRY_PER_BLOCK; i++, start_nid++) {
> + bool freed = false;
>  
>   if (unlikely(start_nid >= nm_i->max_nid))
>   break;
> @@ -1858,8 +1859,8 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
>   blk_addr = le32_to_cpu(nat_blk->entries[i].block_addr);
>   f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
>   if (blk_addr == NULL_ADDR)
> - add_free_nid(sbi, start_nid, true);
> - update_free_nid_bitmap(sbi, start_nid, blk_addr == NULL_ADDR);
> + freed = add_free_nid(sbi, start_nid, true);
> + update_free_nid_bitmap(sbi, start_nid, freed);
>   }
>  }
>  
> 

Re: [PATCH 1/2] media: s5p-mfc: convert drivers to use the new vb2_queue dev field

[pankaj.dubey]

Hello Javier,

On Saturday 25 February 2017 12:52 AM, Javier Martinez Canillas wrote:
> Hello Pankaj,
> 
> On 12/16/2016 08:48 AM, Pankaj Dubey wrote:
>> From: Smitha T Murthy 
>>
>> commit 2548fee63d9e ("[media] media/platform: convert drivers to use the new
>> vb2_queue dev field") has missed to set dev pointer of vb2_queue which will 
>> be
>> used in reqbufs of mfc driver. Without this change following error is 
>> observed:
>>
>> ---
>> V4L2 Codec decoding example application
>> Kamil Debski 
>> Copyright 2012 Samsung Electronics Co., Ltd.
>>
>> Opening MFC.
>> (mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
>> bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
>> 42.339165] Remapping memory failed, error: -6
>>
>> MFC Open Success.
>> (main.c:main:711): Successfully opened all necessary files and devices
>> (mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
>> size=4194304 (requested=4194304)
>> (mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
>> (requested 2)
>>
>> [App] Out buf phy : 0x, virt : 0x
>> Output Length is = 0x30
>> Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
>> ---
>>
> 
> On which kernel version did you face this issue?
> 

We observed this issue, on Linux 4.9 kernel while doing some experiment
for using reserved-memory for MFC on Exynos7880 based development board.

Anyways FYI, This patch is series is superseded by patch [1] after
review comments and suggestion from Marek. Patch [1] has been accepted
and merged and working well for us.

[1]: https://patchwork.kernel.org/patch/9482499/

Thanks,
Pankaj Dubey

>> Signed-off-by: Smitha T Murthy 
>> [pankaj.dubey: debugging issue and formatting commit message]
>> Signed-off-by: Pankaj Dubey 
>> ---
>>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index 0a5b8f5..6ea8246 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -838,6 +838,7 @@ static int s5p_mfc_open(struct file *file)
>>  q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
>>  q->drv_priv = >fh;
>>  q->lock = >mfc_mutex;
>> +q->dev = >plat_dev->dev;
>>  if (vdev == dev->vfd_dec) {
>>  q->io_modes = VB2_MMAP;
>>  q->ops = get_dec_queue_ops();
>> @@ -861,6 +862,7 @@ static int s5p_mfc_open(struct file *file)
>>  q->io_modes = VB2_MMAP;
>>  q->drv_priv = >fh;
>>  q->lock = >mfc_mutex;
>> +q->dev = >plat_dev->dev;
>>  if (vdev == dev->vfd_dec) {
>>  q->io_modes = VB2_MMAP;
>>  q->ops = get_dec_queue_ops();
>>
> 
> Please correct me if I'm wrong, but AFAIU this shouldn't be needed in
> the s5p-mfc driver since the videobuf2 core either uses the vb2_queue
> .dev field or the vb2_queue .alloc_devs. And the latter is set in the
> s5p_mfc_queue_setup() function, so the .dev field shouldn't be used.
> 
> Best regards,
> 

Re: [PATCH 1/2] media: s5p-mfc: convert drivers to use the new vb2_queue dev field

[pankaj.dubey]

Hello Javier,

On Saturday 25 February 2017 12:52 AM, Javier Martinez Canillas wrote:
> Hello Pankaj,
> 
> On 12/16/2016 08:48 AM, Pankaj Dubey wrote:
>> From: Smitha T Murthy 
>>
>> commit 2548fee63d9e ("[media] media/platform: convert drivers to use the new
>> vb2_queue dev field") has missed to set dev pointer of vb2_queue which will 
>> be
>> used in reqbufs of mfc driver. Without this change following error is 
>> observed:
>>
>> ---
>> V4L2 Codec decoding example application
>> Kamil Debski 
>> Copyright 2012 Samsung Electronics Co., Ltd.
>>
>> Opening MFC.
>> (mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
>> bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
>> 42.339165] Remapping memory failed, error: -6
>>
>> MFC Open Success.
>> (main.c:main:711): Successfully opened all necessary files and devices
>> (mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
>> size=4194304 (requested=4194304)
>> (mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
>> (requested 2)
>>
>> [App] Out buf phy : 0x, virt : 0x
>> Output Length is = 0x30
>> Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
>> ---
>>
> 
> On which kernel version did you face this issue?
> 

We observed this issue, on Linux 4.9 kernel while doing some experiment
for using reserved-memory for MFC on Exynos7880 based development board.

Anyways FYI, This patch is series is superseded by patch [1] after
review comments and suggestion from Marek. Patch [1] has been accepted
and merged and working well for us.

[1]: https://patchwork.kernel.org/patch/9482499/

Thanks,
Pankaj Dubey

>> Signed-off-by: Smitha T Murthy 
>> [pankaj.dubey: debugging issue and formatting commit message]
>> Signed-off-by: Pankaj Dubey 
>> ---
>>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index 0a5b8f5..6ea8246 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -838,6 +838,7 @@ static int s5p_mfc_open(struct file *file)
>>  q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
>>  q->drv_priv = >fh;
>>  q->lock = >mfc_mutex;
>> +q->dev = >plat_dev->dev;
>>  if (vdev == dev->vfd_dec) {
>>  q->io_modes = VB2_MMAP;
>>  q->ops = get_dec_queue_ops();
>> @@ -861,6 +862,7 @@ static int s5p_mfc_open(struct file *file)
>>  q->io_modes = VB2_MMAP;
>>  q->drv_priv = >fh;
>>  q->lock = >mfc_mutex;
>> +q->dev = >plat_dev->dev;
>>  if (vdev == dev->vfd_dec) {
>>  q->io_modes = VB2_MMAP;
>>  q->ops = get_dec_queue_ops();
>>
> 
> Please correct me if I'm wrong, but AFAIU this shouldn't be needed in
> the s5p-mfc driver since the videobuf2 core either uses the vb2_queue
> .dev field or the vb2_queue .alloc_devs. And the latter is set in the
> s5p_mfc_queue_setup() function, so the .dev field shouldn't be used.
> 
> Best regards,
> 

Re: [f2fs-dev] [PATCH 2/3] f2fs: add bitmaps for empty or full NAT blocks

[Chao Yu]

On 2017/2/26 2:34, Jaegeuk Kim wrote:
> On 02/25, Chao Yu wrote:
>> On 2017/2/24 6:54, Jaegeuk Kim wrote:
>>> On 02/23, Chao Yu wrote:
 On 2017/2/14 10:06, Jaegeuk Kim wrote:
> ...
>>>
> +static int scan_nat_bits(struct f2fs_sb_info *sbi)
> +{
> + struct f2fs_nm_info *nm_i = NM_I(sbi);
> + struct page *page;
> + unsigned int i = 0;
> + nid_t target = FREE_NID_PAGES * NAT_ENTRY_PER_BLOCK;
> + nid_t nid;
> +
> + if (!is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG))
> + return -EAGAIN;
> +
> + down_read(_i->nat_tree_lock);
> +check_empty:
> + i = find_next_bit_le(nm_i->empty_nat_bits, nm_i->nat_blocks, i);
> + if (i >= nm_i->nat_blocks) {
> + i = 0;
> + goto check_partial;
> + }
> +
> + for (nid = i * NAT_ENTRY_PER_BLOCK; nid < (i + 1) * NAT_ENTRY_PER_BLOCK;
> + nid++) {
> + if (unlikely(nid >= nm_i->max_nid))
> + break;
> + add_free_nid(sbi, nid, true);
> + }
> +
> + if (nm_i->nid_cnt[FREE_NID_LIST] >= target)
> + goto out;
> + i++;
> + goto check_empty;
> +
> +check_partial:
> + i = find_next_zero_bit_le(nm_i->full_nat_bits, nm_i->nat_blocks, i);
> + if (i >= nm_i->nat_blocks) {
> + disable_nat_bits(sbi, true);

 Can this happen in real world? Should be a bug in somewhere?
>>>
>>> It happens, since current design handles full_nat_bits optionally in order
>>> to avoid scanning a whole NAT page to set it back as 1 from 0.
>>
>> All 0 value in full_nat_bits means the NAT block has at least one free nid,
>> right? so if we traverse all such NAT blocks, and still haven't collect 
>> enough
>> *target* number of free nids, we don't have to disable nat bit cache, we can
>> just break out here.
> 
> No, I'm seeing this case:
> 1. mount with full=0, empty=0, which indicates some free nids.
> 2. allocate all there-in free nids, but still full=0, empty=0.
> 3. allocate more free nids.
> ...
> ... checkpoint makes full=1, empty=0
> 
> If there is no checkpoint and it consumes all the free nids, we can see all 0
> value in full_nat_bits which is quite impossible. In that case, I'd prefer
> to stop nat_bits and give fsck.f2fs to revive it back.

Yeah, I can understand that, but what I concern is when there is few free nids
(< target), we still try to load nids of 8 NAT blocks until ending the loop of
caching free nids, so it will be very easy to enter the case of disabling
nid_bits cache here, so how about doing more check?

if (i >= nm_i->nat_blocks &&
nm_i->nid_cnt[FREE_NID_LIST] != nm_i->available_nids)
disable_nat_bits

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>

> + return -EINVAL;
> + }
> +
> + nid = i * NAT_ENTRY_PER_BLOCK;
> + page = get_current_nat_page(sbi, nid);
> + scan_nat_page(sbi, page, nid);
> + f2fs_put_page(page, 1);
> +
> + if (nm_i->nid_cnt[FREE_NID_LIST] < target) {
> + i++;
> + goto check_partial;
> + }
> +out:
> + up_read(_i->nat_tree_lock);
> + return 0;
> +}
> +
> +static void __build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool 
> mount)
>  {
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_HOT_DATA);
> @@ -1854,6 +1911,20 @@ static void __build_free_nids(struct f2fs_sb_info 
> *sbi, bool sync)
>   if (!sync && !available_free_memory(sbi, FREE_NIDS))
>   return;
>  
> + /* try to find free nids with nat_bits */
> + if (!mount && !scan_nat_bits(sbi) && nm_i->nid_cnt[FREE_NID_LIST])
> + return;
> +
> + /* find next valid candidate */

 This is just for mount case?
>>>
>>> Yup, it reuses free nids in dirty NAT blocks, so that we can make them as 
>>> full
>>> NAT pages.
>>>
>>> Thanks,
>>>

> + if (is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG)) {
> + int idx = find_next_zero_bit_le(nm_i->full_nat_bits,
> + nm_i->nat_blocks, 0);
> + if (idx >= nm_i->nat_blocks)
> + set_sbi_flag(sbi, SBI_NEED_FSCK);
> + else
> + nid = idx * NAT_ENTRY_PER_BLOCK;
> + }
> +
>   /* readahead nat pages to be scanned */
>   ra_meta_pages(sbi, NAT_BLOCK_OFFSET(nid), FREE_NID_PAGES,
>   META_NAT, true);
> @@ -1896,10 +1967,10 @@ static void __build_free_nids(struct f2fs_sb_info 
> *sbi, bool sync)
>   nm_i->ra_nid_pages, META_NAT, false);
>  }
>  
> -void build_free_nids(struct f2fs_sb_info *sbi, bool sync)
> +void build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount)
>  {
>   mutex_lock(_I(sbi)->build_lock);
> - __build_free_nids(sbi, 

Re: [f2fs-dev] [PATCH 2/3] f2fs: add bitmaps for empty or full NAT blocks

[Chao Yu]

On 2017/2/26 2:34, Jaegeuk Kim wrote:
> On 02/25, Chao Yu wrote:
>> On 2017/2/24 6:54, Jaegeuk Kim wrote:
>>> On 02/23, Chao Yu wrote:
 On 2017/2/14 10:06, Jaegeuk Kim wrote:
> ...
>>>
> +static int scan_nat_bits(struct f2fs_sb_info *sbi)
> +{
> + struct f2fs_nm_info *nm_i = NM_I(sbi);
> + struct page *page;
> + unsigned int i = 0;
> + nid_t target = FREE_NID_PAGES * NAT_ENTRY_PER_BLOCK;
> + nid_t nid;
> +
> + if (!is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG))
> + return -EAGAIN;
> +
> + down_read(_i->nat_tree_lock);
> +check_empty:
> + i = find_next_bit_le(nm_i->empty_nat_bits, nm_i->nat_blocks, i);
> + if (i >= nm_i->nat_blocks) {
> + i = 0;
> + goto check_partial;
> + }
> +
> + for (nid = i * NAT_ENTRY_PER_BLOCK; nid < (i + 1) * NAT_ENTRY_PER_BLOCK;
> + nid++) {
> + if (unlikely(nid >= nm_i->max_nid))
> + break;
> + add_free_nid(sbi, nid, true);
> + }
> +
> + if (nm_i->nid_cnt[FREE_NID_LIST] >= target)
> + goto out;
> + i++;
> + goto check_empty;
> +
> +check_partial:
> + i = find_next_zero_bit_le(nm_i->full_nat_bits, nm_i->nat_blocks, i);
> + if (i >= nm_i->nat_blocks) {
> + disable_nat_bits(sbi, true);

 Can this happen in real world? Should be a bug in somewhere?
>>>
>>> It happens, since current design handles full_nat_bits optionally in order
>>> to avoid scanning a whole NAT page to set it back as 1 from 0.
>>
>> All 0 value in full_nat_bits means the NAT block has at least one free nid,
>> right? so if we traverse all such NAT blocks, and still haven't collect 
>> enough
>> *target* number of free nids, we don't have to disable nat bit cache, we can
>> just break out here.
> 
> No, I'm seeing this case:
> 1. mount with full=0, empty=0, which indicates some free nids.
> 2. allocate all there-in free nids, but still full=0, empty=0.
> 3. allocate more free nids.
> ...
> ... checkpoint makes full=1, empty=0
> 
> If there is no checkpoint and it consumes all the free nids, we can see all 0
> value in full_nat_bits which is quite impossible. In that case, I'd prefer
> to stop nat_bits and give fsck.f2fs to revive it back.

Yeah, I can understand that, but what I concern is when there is few free nids
(< target), we still try to load nids of 8 NAT blocks until ending the loop of
caching free nids, so it will be very easy to enter the case of disabling
nid_bits cache here, so how about doing more check?

if (i >= nm_i->nat_blocks &&
nm_i->nid_cnt[FREE_NID_LIST] != nm_i->available_nids)
disable_nat_bits

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>

> + return -EINVAL;
> + }
> +
> + nid = i * NAT_ENTRY_PER_BLOCK;
> + page = get_current_nat_page(sbi, nid);
> + scan_nat_page(sbi, page, nid);
> + f2fs_put_page(page, 1);
> +
> + if (nm_i->nid_cnt[FREE_NID_LIST] < target) {
> + i++;
> + goto check_partial;
> + }
> +out:
> + up_read(_i->nat_tree_lock);
> + return 0;
> +}
> +
> +static void __build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool 
> mount)
>  {
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_HOT_DATA);
> @@ -1854,6 +1911,20 @@ static void __build_free_nids(struct f2fs_sb_info 
> *sbi, bool sync)
>   if (!sync && !available_free_memory(sbi, FREE_NIDS))
>   return;
>  
> + /* try to find free nids with nat_bits */
> + if (!mount && !scan_nat_bits(sbi) && nm_i->nid_cnt[FREE_NID_LIST])
> + return;
> +
> + /* find next valid candidate */

 This is just for mount case?
>>>
>>> Yup, it reuses free nids in dirty NAT blocks, so that we can make them as 
>>> full
>>> NAT pages.
>>>
>>> Thanks,
>>>

> + if (is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG)) {
> + int idx = find_next_zero_bit_le(nm_i->full_nat_bits,
> + nm_i->nat_blocks, 0);
> + if (idx >= nm_i->nat_blocks)
> + set_sbi_flag(sbi, SBI_NEED_FSCK);
> + else
> + nid = idx * NAT_ENTRY_PER_BLOCK;
> + }
> +
>   /* readahead nat pages to be scanned */
>   ra_meta_pages(sbi, NAT_BLOCK_OFFSET(nid), FREE_NID_PAGES,
>   META_NAT, true);
> @@ -1896,10 +1967,10 @@ static void __build_free_nids(struct f2fs_sb_info 
> *sbi, bool sync)
>   nm_i->ra_nid_pages, META_NAT, false);
>  }
>  
> -void build_free_nids(struct f2fs_sb_info *sbi, bool sync)
> +void build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount)
>  {
>   mutex_lock(_I(sbi)->build_lock);
> - __build_free_nids(sbi, 

RE: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk

[Y.T. Tang]

PING!

Regards,
Yuantian

> -Original Message-
> From: yuantian.t...@nxp.com [mailto:yuantian.t...@nxp.com]
> Sent: Wednesday, February 15, 2017 1:48 PM
> To: mturque...@baylibre.com
> Cc: sb...@codeaurora.org; robh...@kernel.org; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Y.T. Tang
> ; Scott Wood ; Y.T. Tang
> 
> Subject: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk
> 
> From: Tang Yuantian 
> 
> ls1012a has separate input root clocks for core PLLs versus the platform PLL,
> with the latter described as sysclk in the hw docs.
> Update the qoriq-clock binding to allow a second input clock, named
> "coreclk".  If present, this clock will be used for the core PLLs.
> 
> Signed-off-by: Scott Wood 
> Signed-off-by: Tang Yuantian 
> ---
>  Documentation/devicetree/bindings/clock/qoriq-clock.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index df9cb5a..97a9666 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -55,6 +55,11 @@ Optional properties:
>  - clocks: If clock-frequency is not specified, sysclk may be provided
>   as an input clock.  Either clock-frequency or clocks must be
>   provided.
> + A second input clock, called "coreclk", may be provided if
> + core PLLs are based on a different input clock from the
> + platform PLL.
> +- clock-names: Required if a coreclk is present.  Valid names are
> + "sysclk" and "coreclk".
> 
>  2. Clock Provider
> 
> @@ -71,6 +76,7 @@ second cell is the clock index for the specified type.
>   2   hwaccel index (n in CLKCGnHWACSR)
>   3   fman0 for fm1, 1 for fm2
>   4   platform pll0=pll, 1=pll/2, 2=pll/3, 3=pll/4
> + 5   coreclk must be 0
> 
>  3. Example
> 
> --
> 2.1.0.27.g96db324

RE: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk

[Y.T. Tang]

PING!

Regards,
Yuantian

> -Original Message-
> From: yuantian.t...@nxp.com [mailto:yuantian.t...@nxp.com]
> Sent: Wednesday, February 15, 2017 1:48 PM
> To: mturque...@baylibre.com
> Cc: sb...@codeaurora.org; robh...@kernel.org; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Y.T. Tang
> ; Scott Wood ; Y.T. Tang
> 
> Subject: [PATCH 1/2] dt-bindings: qoriq-clock: Add coreclk
> 
> From: Tang Yuantian 
> 
> ls1012a has separate input root clocks for core PLLs versus the platform PLL,
> with the latter described as sysclk in the hw docs.
> Update the qoriq-clock binding to allow a second input clock, named
> "coreclk".  If present, this clock will be used for the core PLLs.
> 
> Signed-off-by: Scott Wood 
> Signed-off-by: Tang Yuantian 
> ---
>  Documentation/devicetree/bindings/clock/qoriq-clock.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index df9cb5a..97a9666 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -55,6 +55,11 @@ Optional properties:
>  - clocks: If clock-frequency is not specified, sysclk may be provided
>   as an input clock.  Either clock-frequency or clocks must be
>   provided.
> + A second input clock, called "coreclk", may be provided if
> + core PLLs are based on a different input clock from the
> + platform PLL.
> +- clock-names: Required if a coreclk is present.  Valid names are
> + "sysclk" and "coreclk".
> 
>  2. Clock Provider
> 
> @@ -71,6 +76,7 @@ second cell is the clock index for the specified type.
>   2   hwaccel index (n in CLKCGnHWACSR)
>   3   fman0 for fm1, 1 for fm2
>   4   platform pll0=pll, 1=pll/2, 2=pll/3, 3=pll/4
> + 5   coreclk must be 0
> 
>  3. Example
> 
> --
> 2.1.0.27.g96db324

Re: [PATCH v2 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board

[Alex Elder]

On 02/26/2017 07:24 PM, Jiancheng Xue wrote:
> Hi Andreas,
> 
> On 2017/2/26 9:32, Andreas Färber wrote:
>> Am 22.02.2017 um 09:38 schrieb Jiancheng Xue:
>>> Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board.
>>>
>>> Signed-off-by: Jiancheng Xue 
>>> ---
>>>  Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
>>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> index f1c1e21..1fd3dd7 100644
>>> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> @@ -4,6 +4,10 @@ Hi3660 SoC
>>>  Required root node properties:
>>> - compatible = "hisilicon,hi3660";
>>>  
>>> +Hi3798cv200 Poplar Board
>>> +Required root node properties:
>>> +   - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
>>
>> Please remember to CC previous reviewers.
>>
> Sorry for that.
> 
>> This still looks wrong: Why is this not "hisilicon,poplar" if you choose
>> against "tocoding,poplar"? 
> 
> I didn't think it was very important thing whether the compatbile string 
> contained
> a preceding SoC name or not. I just referred to the hikey board and some other
> HiSilicon boards. I wanted to keep using the same rule with them.

The way Jiancheng defined this was consistent with the pattern
used for all other definitions of platforms found in this
documentation file.  Why make this one different?

>> Is there a second Poplar board with a different SoC? 
> 
> I can't tell about this now.

There is not.  But there could be.  In any case, I do accept
your point that there's no need to encode the SoC identity
in the board compatible string.  But I don't think doing so
causes harm.

>> Even then it would be redundant with the second
>> compatible string.

I presume you're not arguing that the second compatible
string should be eliminated; it seems your concern is only
about including the SoC in the board's compatible string.
Is that right?

> The second compatilbe string can be removed here. Thanks.

I don't think it should be.

My position, for what it's worth, is that if a change is
made to the compatible strings, it should be:

  compatible = "hisilicon,poplar", "hisilicon,hi3798cv200";

But I don't think it's necessary to make that change.  Tocoding
has no other DT presence in the kernel right now; it seems fine
to tag the board with "hisilicon".

-Alex

> 
> Regards,
> Jiancheng
> 
>> Regards,
>> Andreas
>>
>>> +
>>>  Hi4511 Board
>>>  Required root node properties:
>>> - compatible = "hisilicon,hi3620-hi4511";
>>
> 

Re: [PATCH v2 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board

[Alex Elder]

On 02/26/2017 07:24 PM, Jiancheng Xue wrote:
> Hi Andreas,
> 
> On 2017/2/26 9:32, Andreas Färber wrote:
>> Am 22.02.2017 um 09:38 schrieb Jiancheng Xue:
>>> Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board.
>>>
>>> Signed-off-by: Jiancheng Xue 
>>> ---
>>>  Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
>>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> index f1c1e21..1fd3dd7 100644
>>> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>>> @@ -4,6 +4,10 @@ Hi3660 SoC
>>>  Required root node properties:
>>> - compatible = "hisilicon,hi3660";
>>>  
>>> +Hi3798cv200 Poplar Board
>>> +Required root node properties:
>>> +   - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
>>
>> Please remember to CC previous reviewers.
>>
> Sorry for that.
> 
>> This still looks wrong: Why is this not "hisilicon,poplar" if you choose
>> against "tocoding,poplar"? 
> 
> I didn't think it was very important thing whether the compatbile string 
> contained
> a preceding SoC name or not. I just referred to the hikey board and some other
> HiSilicon boards. I wanted to keep using the same rule with them.

The way Jiancheng defined this was consistent with the pattern
used for all other definitions of platforms found in this
documentation file.  Why make this one different?

>> Is there a second Poplar board with a different SoC? 
> 
> I can't tell about this now.

There is not.  But there could be.  In any case, I do accept
your point that there's no need to encode the SoC identity
in the board compatible string.  But I don't think doing so
causes harm.

>> Even then it would be redundant with the second
>> compatible string.

I presume you're not arguing that the second compatible
string should be eliminated; it seems your concern is only
about including the SoC in the board's compatible string.
Is that right?

> The second compatilbe string can be removed here. Thanks.

I don't think it should be.

My position, for what it's worth, is that if a change is
made to the compatible strings, it should be:

  compatible = "hisilicon,poplar", "hisilicon,hi3798cv200";

But I don't think it's necessary to make that change.  Tocoding
has no other DT presence in the kernel right now; it seems fine
to tag the board with "hisilicon".

-Alex

> 
> Regards,
> Jiancheng
> 
>> Regards,
>> Andreas
>>
>>> +
>>>  Hi4511 Board
>>>  Required root node properties:
>>> - compatible = "hisilicon,hi3620-hi4511";
>>
> 

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > :
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> >>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
> >>> >> >> >>> > >still has objects
> >>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >>> >> >> >>> > >4.10.0-rc3 #2
> >>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox
> 12/01/2006
> >>> >> >> >>> > >[0.188000] Call Trace:
> >>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>> >> >> >>>
> >>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED 
> >>> >> >> >>> error.
> >>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
> >>> >> >> >>> "acpidump -c on" and
> "acpidump -c off" output?
> >>> >> >>
> >>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >>> >> >> Here are raw dumps of table.
> >>> >> >
> >>> >> > So, excuse me, but what's the security issue here?
> >>> >> >
> >>> >> > You hacked your ACPI tables into pieces which requires root 

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > :
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> >>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
> >>> >> >> >>> > >still has objects
> >>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >>> >> >> >>> > >4.10.0-rc3 #2
> >>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox
> 12/01/2006
> >>> >> >> >>> > >[0.188000] Call Trace:
> >>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>> >> >> >>>
> >>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED 
> >>> >> >> >>> error.
> >>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
> >>> >> >> >>> "acpidump -c on" and
> "acpidump -c off" output?
> >>> >> >>
> >>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >>> >> >> Here are raw dumps of table.
> >>> >> >
> >>> >> > So, excuse me, but what's the security issue here?
> >>> >> >
> >>> >> > You hacked your ACPI tables into pieces which requires root 
> >>> >> > privileges anyway.
> >>> >> >
> >>> >> > Thanks,
> >>> >> > Rafael
> >>> >> >
> >>> >>
> >>> >> As you 

[PATCH 25/34] staging: lustre: lnet: change lnet_event_t to proper structure

[James Simmons]

Change lnet_event_t from typedef to proper structure.

Signed-off-by: James Simmons 
Reviewed-on: https://review.whamcloud.com/20831
Reviewed-by: Olaf Weber 
Reviewed-by: Doug Oucharek 
Reviewed-by: Dmitry Eremin 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/include/linux/lnet/api.h   |  4 ++--
 drivers/staging/lustre/include/linux/lnet/lib-lnet.h  |  4 ++--
 drivers/staging/lustre/include/linux/lnet/lib-types.h |  4 ++--
 drivers/staging/lustre/include/linux/lnet/types.h |  6 +++---
 drivers/staging/lustre/lnet/lnet/api-ni.c |  4 ++--
 drivers/staging/lustre/lnet/lnet/lib-eq.c | 16 
 drivers/staging/lustre/lnet/lnet/lib-md.c |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-me.c |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-move.c   |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-msg.c|  8 
 drivers/staging/lustre/lnet/lnet/router.c |  2 +-
 drivers/staging/lustre/lnet/selftest/rpc.c|  2 +-
 drivers/staging/lustre/lustre/include/lustre_net.h| 12 ++--
 drivers/staging/lustre/lustre/ptlrpc/events.c | 14 +++---
 14 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/api.h 
b/drivers/staging/lustre/include/linux/lnet/api.h
index 8609206..b46a769 100644
--- a/drivers/staging/lustre/include/linux/lnet/api.h
+++ b/drivers/staging/lustre/include/linux/lnet/api.h
@@ -148,7 +148,7 @@ int LNetMDBind(struct lnet_md md_in,
  *
  * In addition to the lnet_handle_eq, the LNet API defines two types
  * associated with events: The ::lnet_event_kind_t defines the kinds of events
- * that can be stored in an EQ. The lnet_event_t defines a structure that
+ * that can be stored in an EQ. The lnet_event defines a structure that
  * holds the information about with an event.
  *
  * There are five functions for dealing with EQs: LNetEQAlloc() is used to
@@ -168,7 +168,7 @@ int LNetEQAlloc(unsigned int   count_in,
 int LNetEQPoll(struct lnet_handle_eq *eventqs_in,
   int   neq_in,
   int   timeout_ms,
-  lnet_event_t *event_out,
+  struct lnet_event *event_out,
   int  *which_eq_out);
 /** @} lnet_eq */
 
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index a6cf5be..d770a03 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -485,12 +485,12 @@ int lnet_dyn_add_ni(lnet_pid_t requested_pid,
 void lnet_msg_attach_md(struct lnet_msg *msg, struct lnet_libmd *md,
unsigned int offset, unsigned int mlen);
 void lnet_msg_detach_md(struct lnet_msg *msg, int status);
-void lnet_build_unlink_event(struct lnet_libmd *md, lnet_event_t *ev);
+void lnet_build_unlink_event(struct lnet_libmd *md, struct lnet_event *ev);
 void lnet_build_msg_event(struct lnet_msg *msg, lnet_event_kind_t ev_type);
 void lnet_msg_commit(struct lnet_msg *msg, int cpt);
 void lnet_msg_decommit(struct lnet_msg *msg, int cpt, int status);
 
-void lnet_eq_enqueue_event(struct lnet_eq *eq, lnet_event_t *ev);
+void lnet_eq_enqueue_event(struct lnet_eq *eq, struct lnet_event *ev);
 void lnet_prep_send(struct lnet_msg *msg, int type, lnet_process_id_t target,
unsigned int offset, unsigned int len);
 int lnet_send(lnet_nid_t nid, struct lnet_msg *msg, lnet_nid_t rtr_nid);
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index c98af93..808a05c 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -104,7 +104,7 @@ struct lnet_msg {
struct kvec *msg_iov;
lnet_kiov_t *msg_kiov;
 
-   lnet_event_t msg_ev;
+   struct lnet_eventmsg_ev;
struct lnet_hdr  msg_hdr;
 };
 
@@ -123,7 +123,7 @@ struct lnet_eq {
lnet_seq_teq_deq_seq;
unsigned int  eq_size;
lnet_eq_handler_t eq_callback;
-   lnet_event_t *eq_events;
+   struct lnet_event*eq_events;
int **eq_refs;  /* percpt refcount for EQ */
 };
 
diff --git a/drivers/staging/lustre/include/linux/lnet/types.h 
b/drivers/staging/lustre/include/linux/lnet/types.h
index bc3f3e3..53eb1da 100644
--- a/drivers/staging/lustre/include/linux/lnet/types.h
+++ b/drivers/staging/lustre/include/linux/lnet/types.h
@@ -568,7 +568,7 @@ struct lnet_md {
 /**
  * Information about an event on a MD.
  */
-typedef struct {
+struct lnet_event {
/** 

[PATCH 25/34] staging: lustre: lnet: change lnet_event_t to proper structure

[James Simmons]

Change lnet_event_t from typedef to proper structure.

Signed-off-by: James Simmons 
Reviewed-on: https://review.whamcloud.com/20831
Reviewed-by: Olaf Weber 
Reviewed-by: Doug Oucharek 
Reviewed-by: Dmitry Eremin 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/include/linux/lnet/api.h   |  4 ++--
 drivers/staging/lustre/include/linux/lnet/lib-lnet.h  |  4 ++--
 drivers/staging/lustre/include/linux/lnet/lib-types.h |  4 ++--
 drivers/staging/lustre/include/linux/lnet/types.h |  6 +++---
 drivers/staging/lustre/lnet/lnet/api-ni.c |  4 ++--
 drivers/staging/lustre/lnet/lnet/lib-eq.c | 16 
 drivers/staging/lustre/lnet/lnet/lib-md.c |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-me.c |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-move.c   |  2 +-
 drivers/staging/lustre/lnet/lnet/lib-msg.c|  8 
 drivers/staging/lustre/lnet/lnet/router.c |  2 +-
 drivers/staging/lustre/lnet/selftest/rpc.c|  2 +-
 drivers/staging/lustre/lustre/include/lustre_net.h| 12 ++--
 drivers/staging/lustre/lustre/ptlrpc/events.c | 14 +++---
 14 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/api.h 
b/drivers/staging/lustre/include/linux/lnet/api.h
index 8609206..b46a769 100644
--- a/drivers/staging/lustre/include/linux/lnet/api.h
+++ b/drivers/staging/lustre/include/linux/lnet/api.h
@@ -148,7 +148,7 @@ int LNetMDBind(struct lnet_md md_in,
  *
  * In addition to the lnet_handle_eq, the LNet API defines two types
  * associated with events: The ::lnet_event_kind_t defines the kinds of events
- * that can be stored in an EQ. The lnet_event_t defines a structure that
+ * that can be stored in an EQ. The lnet_event defines a structure that
  * holds the information about with an event.
  *
  * There are five functions for dealing with EQs: LNetEQAlloc() is used to
@@ -168,7 +168,7 @@ int LNetEQAlloc(unsigned int   count_in,
 int LNetEQPoll(struct lnet_handle_eq *eventqs_in,
   int   neq_in,
   int   timeout_ms,
-  lnet_event_t *event_out,
+  struct lnet_event *event_out,
   int  *which_eq_out);
 /** @} lnet_eq */
 
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index a6cf5be..d770a03 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -485,12 +485,12 @@ int lnet_dyn_add_ni(lnet_pid_t requested_pid,
 void lnet_msg_attach_md(struct lnet_msg *msg, struct lnet_libmd *md,
unsigned int offset, unsigned int mlen);
 void lnet_msg_detach_md(struct lnet_msg *msg, int status);
-void lnet_build_unlink_event(struct lnet_libmd *md, lnet_event_t *ev);
+void lnet_build_unlink_event(struct lnet_libmd *md, struct lnet_event *ev);
 void lnet_build_msg_event(struct lnet_msg *msg, lnet_event_kind_t ev_type);
 void lnet_msg_commit(struct lnet_msg *msg, int cpt);
 void lnet_msg_decommit(struct lnet_msg *msg, int cpt, int status);
 
-void lnet_eq_enqueue_event(struct lnet_eq *eq, lnet_event_t *ev);
+void lnet_eq_enqueue_event(struct lnet_eq *eq, struct lnet_event *ev);
 void lnet_prep_send(struct lnet_msg *msg, int type, lnet_process_id_t target,
unsigned int offset, unsigned int len);
 int lnet_send(lnet_nid_t nid, struct lnet_msg *msg, lnet_nid_t rtr_nid);
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index c98af93..808a05c 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -104,7 +104,7 @@ struct lnet_msg {
struct kvec *msg_iov;
lnet_kiov_t *msg_kiov;
 
-   lnet_event_t msg_ev;
+   struct lnet_eventmsg_ev;
struct lnet_hdr  msg_hdr;
 };
 
@@ -123,7 +123,7 @@ struct lnet_eq {
lnet_seq_teq_deq_seq;
unsigned int  eq_size;
lnet_eq_handler_t eq_callback;
-   lnet_event_t *eq_events;
+   struct lnet_event*eq_events;
int **eq_refs;  /* percpt refcount for EQ */
 };
 
diff --git a/drivers/staging/lustre/include/linux/lnet/types.h 
b/drivers/staging/lustre/include/linux/lnet/types.h
index bc3f3e3..53eb1da 100644
--- a/drivers/staging/lustre/include/linux/lnet/types.h
+++ b/drivers/staging/lustre/include/linux/lnet/types.h
@@ -568,7 +568,7 @@ struct lnet_md {
 /**
  * Information about an event on a MD.
  */
-typedef struct {
+struct lnet_event {
/** The identifier (nid, pid) of the target. */
lnet_process_id_t   target;
/** The identifier (nid, pid) of the 

Re: [PATCH] lib: Allow compile-testing of parman

[David Miller]

From: Geert Uytterhoeven 
Date: Fri, 24 Feb 2017 11:25:55 +0100

> This allows to enable and run the accompanying test (test_parman)
> without dependencies on other users of parman.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks.

Re: [PATCH] lib: Allow compile-testing of parman

[David Miller]

From: Geert Uytterhoeven 
Date: Fri, 24 Feb 2017 11:25:55 +0100

> This allows to enable and run the accompanying test (test_parman)
> without dependencies on other users of parman.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks.

[PATCHv3 3/4] Removing mixed spaces/hard-tabs in the alignment indentation to appease checkpatch.

[Matthew Giassa]

---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 0aa402d..9f71f01 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -20,8 +20,8 @@
 /* (SIOCIWFIRSTPRIV + 2) */
 #define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
-#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
 #define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
 #define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
-- 
2.7.4

[PATCHv3 3/4] Removing mixed spaces/hard-tabs in the alignment indentation to appease checkpatch.

[Matthew Giassa]

---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 0aa402d..9f71f01 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -20,8 +20,8 @@
 /* (SIOCIWFIRSTPRIV + 2) */
 #define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
-#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_ENABLE (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE (SIOCIWFIRSTPRIV + 5)
 #define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
 #define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
-- 
2.7.4