[PATCH 1/1 linux-next] fs/affs: free affs_sb_info in put_super()

kill_block_super() calls generic_shutdown_super() calling FS put_user() where we generally free superblock specific information. This removes unneeded affs_kill_sb() sbi is automatically reserved in fill_super() so there is no need to test it. Signed-off-by: Fabian Frederick

[PATCH] c6x/timer64: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

[PATCH 1/1 linux-next] fs/affs: free affs_sb_info in put_super()

kill_block_super() calls generic_shutdown_super() calling FS put_user() where we generally free superblock specific information. This removes unneeded affs_kill_sb() sbi is automatically reserved in fill_super() so there is no need to test it. Signed-off-by: Fabian Frederick ---

[PATCH] c6x/timer64: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote: > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala > wrote: > > Hi, > > > > Running: > > > > $ sudo x86info -a > > > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and > >

Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote: > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala > wrote: > > Hi, > > > > Running: > > > > $ sudo x86info -a > > > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and > > produces the following kernel

[PATCH] blackfin: time-ts: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

[PATCH net v2] openvswitch: Fix ovs_flow_key_update()

ovs_flow_key_update() is called when the flow key is invalid, and it is used to update and revalidate the flow key. Commit 329f45bc4f19 ("openvswitch: add mac_proto field to the flow key") introduces mac_proto field to flow key and use it to determine whether the flow key is valid. However, the

[PATCH] blackfin: time-ts: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

[PATCH net v2] openvswitch: Fix ovs_flow_key_update()

ovs_flow_key_update() is called when the flow key is invalid, and it is used to update and revalidate the flow key. Commit 329f45bc4f19 ("openvswitch: add mac_proto field to the flow key") introduces mac_proto field to flow key and use it to determine whether the flow key is valid. However, the

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

On Thu, Mar 30, 2017 at 8:51 AM, Johannes Weiner wrote: > In cgroup2, we've added a memory.low knob, where groups within their > memory.low setting are not reclaimed. > > You can set that knob on foreground groups to the amount of memory > they need to function properly, and

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

On Thu, Mar 30, 2017 at 8:51 AM, Johannes Weiner wrote: > In cgroup2, we've added a memory.low knob, where groups within their > memory.low setting are not reclaimed. > > You can set that knob on foreground groups to the amount of memory > they need to function properly, and set it to 0 on

[PATCH] avr32/time: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

[PATCH] avr32/time: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

Re: [PATCH 1/2] virtio: allow drivers to validate features

From: "Michael S. Tsirkin" Date: Wed, 29 Mar 2017 20:14:44 +0300 > Some drivers can't support all features in all configurations. At the > moment we blindly set FEATURES_OK and later FAILED. Support this better > by adding a callback drivers can use to do some early checks. >

Re: [PATCH 1/2] virtio: allow drivers to validate features

From: "Michael S. Tsirkin" Date: Wed, 29 Mar 2017 20:14:44 +0300 > Some drivers can't support all features in all configurations. At the > moment we blindly set FEATURES_OK and later FAILED. Support this better > by adding a callback drivers can use to do some early checks. > > Signed-off-by:

Re: [RFCv2] arm64: support HAVE_ARCH_RARE_WRITE and HAVE_ARCH_RARE_WRITE_MEMCPY

On Thu, Mar 30, 2017 at 7:39 AM, Hoeun Ryu wrote: > This patch might be a part of Kees Cook's rare_write infrastructure series > for [1] for arm64 architecture. > > This implementation is based on Mark Rutland's suggestions [2], which is > that a special userspace mm that

Re: [RFCv2] arm64: support HAVE_ARCH_RARE_WRITE and HAVE_ARCH_RARE_WRITE_MEMCPY

On Thu, Mar 30, 2017 at 7:39 AM, Hoeun Ryu wrote: > This patch might be a part of Kees Cook's rare_write infrastructure series > for [1] for arm64 architecture. > > This implementation is based on Mark Rutland's suggestions [2], which is > that a special userspace mm that maps only

Re: Apparent backward time travel in timestamps on file creation

Linus Torvalds wrote: > The difference can be quite noticeable - basically the > "gettimeofday()" time will interpolate within timer ticks, while > "xtime" is just the truncated "time at timer tick" value _without_ the > correction. Is there any way to determine

Re: Apparent backward time travel in timestamps on file creation

Linus Torvalds wrote: > The difference can be quite noticeable - basically the > "gettimeofday()" time will interpolate within timer ticks, while > "xtime" is just the truncated "time at timer tick" value _without_ the > correction. Is there any way to determine the error bar, do you know? Or

Re: [v5 3/4] mmc: sdhci-cadence: Update PHY delay configuration

On 21 March 2017 at 15:33, Piotr Sroka wrote: > DTS properties are used instead of fixed data > because PHY settings can be different for different chips/boards. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- >

Re: [v5 3/4] mmc: sdhci-cadence: Update PHY delay configuration

On 21 March 2017 at 15:33, Piotr Sroka wrote: > DTS properties are used instead of fixed data > because PHY settings can be different for different chips/boards. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- > Changes for v2: > - dts part was removed from

Re: [PATCH v2 2/2] mmc: sdhci-pci: Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel controllers

On 29 March 2017 at 20:16, Azhar Shaikh wrote: > Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel SD card > controllers. > > Signed-off-by: Azhar Shaikh Thanks, applied for next! Kind regards Uffe > --- > Changes in v2: > - Rebased the patch

Re: [PATCH v2 2/2] mmc: sdhci-pci: Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel controllers

On 29 March 2017 at 20:16, Azhar Shaikh wrote: > Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel SD card > controllers. > > Signed-off-by: Azhar Shaikh Thanks, applied for next! Kind regards Uffe > --- > Changes in v2: > - Rebased the patch on top of 'next' branch. > - No code change. >

Re: [PATCH] mmc: host: s3cmci: fix broken conditional expression

On 29 March 2017 at 11:52, Arnd Bergmann wrote: > The DT support introduced a typo that gcc detects when -Wempty-body > is enabled: > > drivers/mmc/host/s3cmci.c: In function 's3cmci_probe_pdata': > drivers/mmc/host/s3cmci.c:1543:29: error: suggest braces around empty body in > an

Re: [PATCH] mmc: host: s3cmci: fix broken conditional expression

On 29 March 2017 at 11:52, Arnd Bergmann wrote: > The DT support introduced a typo that gcc detects when -Wempty-body > is enabled: > > drivers/mmc/host/s3cmci.c: In function 's3cmci_probe_pdata': > drivers/mmc/host/s3cmci.c:1543:29: error: suggest braces around empty body in > an 'if' statement

Re: [PATCH v2 1/2] mmc: sdhci-acpi: Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel controllers

On 29 March 2017 at 20:16, Azhar Shaikh wrote: > Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel SD card > controllers. > > Signed-off-by: Azhar Shaikh Thanks, applied for next! Kind regards Uffe > --- > Changes in v2: > - Rebased the patch

Re: [PATCH v2 1/2] mmc: sdhci-acpi: Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel controllers

On 29 March 2017 at 20:16, Azhar Shaikh wrote: > Set MMC_CAP_AGGRESSIVE_PM for BYT-related Intel SD card > controllers. > > Signed-off-by: Azhar Shaikh Thanks, applied for next! Kind regards Uffe > --- > Changes in v2: > - Rebased the patch on top of 'next' branch. > - No code change. >

Re: [v5 2/4] dt-bindings: mmc: add description of PHY delays for sdhci-cadence

On 21 March 2017 at 15:33, Piotr Sroka wrote: > DTS properties are used instead of fixed data > because PHY settings can be different for different chips/boards. > Add description of new DLL PHY delays. > > Signed-off-by: Piotr Sroka Thanks, applied for

Re: [v5 2/4] dt-bindings: mmc: add description of PHY delays for sdhci-cadence

On 21 March 2017 at 15:33, Piotr Sroka wrote: > DTS properties are used instead of fixed data > because PHY settings can be different for different chips/boards. > Add description of new DLL PHY delays. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- >

Re: [PATCH] mmc: sdhci-of-at91: fix MMC_DDR_52 timing selection

On 28 March 2017 at 11:00, Ludovic Desroches wrote: > The controller has different timings for MMC_TIMING_UHS_DDR50 and > MMC_TIMING_MMC_DDR52. Configuring the controller with SDHCI_CTRL_UHS_DDR50, > when MMC_TIMING_MMC_DDR52 timings are requested, is not correct

Re: [v5 1/4] mmc: sdhci-cadence: Fix writing PHY delay

On 21 March 2017 at 15:32, Piotr Sroka wrote: > Add polling for ACK to be sure that data are written to PHY register. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- > Changes for v2: > - fix indent > --- > Changes for

Re: [PATCH] mmc: sdhci-of-at91: fix MMC_DDR_52 timing selection

On 28 March 2017 at 11:00, Ludovic Desroches wrote: > The controller has different timings for MMC_TIMING_UHS_DDR50 and > MMC_TIMING_MMC_DDR52. Configuring the controller with SDHCI_CTRL_UHS_DDR50, > when MMC_TIMING_MMC_DDR52 timings are requested, is not correct and can > lead to unexpected

Re: [v5 1/4] mmc: sdhci-cadence: Fix writing PHY delay

On 21 March 2017 at 15:32, Piotr Sroka wrote: > Add polling for ACK to be sure that data are written to PHY register. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- > Changes for v2: > - fix indent > --- > Changes for v3: > - none > --- > Changes for v4: > -

Re: [dm-devel] [PATCH][RFC] dm raid: Fix NULL pointer dereference for raid1 without bitmap

Acked-by: Heinz Mauelshagen This is the simplest way to solve the issue at hand (bitmap_load() returns success with non-existing bitmap). Heinz On 03/30/2017 05:14 PM, km...@yandex-team.ru wrote: From: Dmitry Bilunov 4257e08 introduces a bitmap

Re: [v5 4/4] mmc: sdhci-cadence: refactor probe function

On 21 March 2017 at 15:33, Piotr Sroka wrote: > Use added dev variable for devm_clk_get. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- > Changes for v5: > - patch created in v5 > --- >

Re: [dm-devel] [PATCH][RFC] dm raid: Fix NULL pointer dereference for raid1 without bitmap

Acked-by: Heinz Mauelshagen This is the simplest way to solve the issue at hand (bitmap_load() returns success with non-existing bitmap). Heinz On 03/30/2017 05:14 PM, km...@yandex-team.ru wrote: From: Dmitry Bilunov 4257e08 introduces a bitmap resize call during preresume phase. User can

Re: [v5 4/4] mmc: sdhci-cadence: refactor probe function

On 21 March 2017 at 15:33, Piotr Sroka wrote: > Use added dev variable for devm_clk_get. > > Signed-off-by: Piotr Sroka Thanks, applied for next! Kind regards Uffe > --- > Changes for v5: > - patch created in v5 > --- > drivers/mmc/host/sdhci-cadence.c | 2 +- > 1 file changed, 1

Re: RFC: reject unknown open flags

* Linus Torvalds: > But probing for flags is why we *could* add things like O_NOATIME etc > - exactly because it "just worked" with old kernels, and people could > just use the new flags knowing that it was a no-op on old kernels. Right, it mostly works for the flags we added. > The whole

Re: [PATCH v3 0/6] bus: brcmstb_gisb: add support for GISBv7 arbiter

On 03/30/2017 11:19 AM, Mark Rutland wrote: > On Thu, Mar 30, 2017 at 09:33:32AM -0700, Florian Fainelli wrote: >> On 03/29/2017 05:29 PM, Doug Berger wrote: >>> This patch set contains changes to enable the GISB arbiter driver >>> on the latest ARM64 architecture Set-Top Box chips from Broadcom.

Re: RFC: reject unknown open flags

* Linus Torvalds: > But probing for flags is why we *could* add things like O_NOATIME etc > - exactly because it "just worked" with old kernels, and people could > just use the new flags knowing that it was a no-op on old kernels. Right, it mostly works for the flags we added. > The whole

Re: [PATCH v3 0/6] bus: brcmstb_gisb: add support for GISBv7 arbiter

On 03/30/2017 11:19 AM, Mark Rutland wrote: > On Thu, Mar 30, 2017 at 09:33:32AM -0700, Florian Fainelli wrote: >> On 03/29/2017 05:29 PM, Doug Berger wrote: >>> This patch set contains changes to enable the GISB arbiter driver >>> on the latest ARM64 architecture Set-Top Box chips from Broadcom.

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 12:21 PM, Andy Lutomirski wrote: > > Huh? Aren't those REX prefixes interpreted as INC instructions or > similar in compat mode? Hmm. I think you're right. So it's not like x32 that runs in long mode but then would use the 64-bit ptrace interface

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 12:21 PM, Andy Lutomirski wrote: > > Huh? Aren't those REX prefixes interpreted as INC instructions or > similar in compat mode? Hmm. I think you're right. So it's not like x32 that runs in long mode but then would use the 64-bit ptrace interface anyway. Your statement

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 12:11 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:59 AM, Andy Lutomirski wrote: >>> >>> And then actually run such a kernel on a 32-bit distro, and verifying >>> that things like gdb and strace really work.

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 12:11 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:59 AM, Andy Lutomirski wrote: >>> >>> And then actually run such a kernel on a 32-bit distro, and verifying >>> that things like gdb and strace really work. But it needs real >>> testing, not some kind of

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 12:10 PM, Al Viro wrote: > > That they very definitely should not. And not because of access_ok() or > might_fault() - this is one place where zero-padding is absolutely wrong. > So unless you are going to take it out of copy_from_user() and pray

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 12:10 PM, Al Viro wrote: > > That they very definitely should not. And not because of access_ok() or > might_fault() - this is one place where zero-padding is absolutely wrong. > So unless you are going to take it out of copy_from_user() and pray > that random shit ioctls

Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 12:02 PM, Paul Eggert wrote: > >> I'm assuming you'd also possible want to be able to use F_SETFL to set >> O_ATOMIC after the fact > > Just for fun, one thread can set O_ATOMIC at the same time another thread is > doing a 'write' I'm sure that

Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 12:02 PM, Paul Eggert wrote: > >> I'm assuming you'd also possible want to be able to use F_SETFL to set >> O_ATOMIC after the fact > > Just for fun, one thread can set O_ATOMIC at the same time another thread is > doing a 'write' I'm sure that falls under "if you

[GIT PULL] bcm2835-dt-next-2017-03-30

Hi Florian, Here's the pull request for those changes I'd misplaced from 4.11. This may be my last PR of the cycle. The only change I have left on my radar for 4.12 is http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/006097.html The following changes since commit

[GIT PULL] bcm2835-dt-next-2017-03-30

Hi Florian, Here's the pull request for those changes I'd misplaced from 4.11. This may be my last PR of the cycle. The only change I have left on my radar for 4.12 is http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/006097.html The following changes since commit

Re: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use

Re: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use case face. > >

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 11:59 AM, Andy Lutomirski wrote: >> >> And then actually run such a kernel on a 32-bit distro, and verifying >> that things like gdb and strace really work. But it needs real >> testing, not some kind of handwaving. It's a *big* change. > > I'll offer

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 11:59 AM, Andy Lutomirski wrote: >> >> And then actually run such a kernel on a 32-bit distro, and verifying >> that things like gdb and strace really work. But it needs real >> testing, not some kind of handwaving. It's a *big* change. > > I'll offer the following

Re: [PATCH RFC 1/4] proc: add proc_fs_info struct to store proc options

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > This is a preparation patch that adds a proc_fs_info to be able to store > different procfs options. Right now some mount options are stored inside > the pid namespace which make multiple proc share the same mount options.

Re: [PATCH RFC 1/4] proc: add proc_fs_info struct to store proc options

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > This is a preparation patch that adds a proc_fs_info to be able to store > different procfs options. Right now some mount options are stored inside > the pid namespace which make multiple proc share the same mount options. > This patch will

Re: [PATCH RFC 3/4] proc: support mounting new procfs instances inside same pid namespace

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > This patch adds support for 'unshare' mount option to have multiple > separated procfs inside the same pid namespace. This allows to solve lot > of problem for containers and their specific use cases. It would be nice if

Re: [PATCH RFC 3/4] proc: support mounting new procfs instances inside same pid namespace

On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > This patch adds support for 'unshare' mount option to have multiple > separated procfs inside the same pid namespace. This allows to solve lot > of problem for containers and their specific use cases. It would be nice if we could make this

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:59:16AM -0700, Linus Torvalds wrote: > But regardless of that, I think you're being silly to even look at the > iovec code. That code simply *isn't* critical enough that one or two > extra instructions matter. > > Show me profiles to the contrary. I dare you. > >

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:59:16AM -0700, Linus Torvalds wrote: > But regardless of that, I think you're being silly to even look at the > iovec code. That code simply *isn't* critical enough that one or two > extra instructions matter. > > Show me profiles to the contrary. I dare you. > >

Re: RFC: reject unknown open flags

On 03/30/2017 11:19 AM, Linus Torvalds wrote: like "dd" growing an atomic flag and setting it on stdout), 'dd' typically assumes that if a flag O_FOO is not #defined by , then 'dd' can "#define O_FOO 0" and the rest of dd's code can assume O_FOO works "well enough" on older systems. I hope

Re: RFC: reject unknown open flags

On 03/30/2017 11:19 AM, Linus Torvalds wrote: like "dd" growing an atomic flag and setting it on stdout), 'dd' typically assumes that if a flag O_FOO is not #defined by , then 'dd' can "#define O_FOO 0" and the rest of dd's code can assume O_FOO works "well enough" on older systems. I hope

Re: [PATCH 7/8] x86/intel_rdt: schemata file support for MBA prepare\

On Wed, 1 Mar 2017, Thomas Gleixner wrote: On Fri, 17 Feb 2017, Vikas Shivappa wrote: Subject: x86/intel_rdt: schemata file support for MBA prepare I have no idea what MBA prepare is. Is that yet another variant aside of MBE? Add support to introduce generic APIs for control validation

Re: [PATCH 7/8] x86/intel_rdt: schemata file support for MBA prepare\

On Wed, 1 Mar 2017, Thomas Gleixner wrote: On Fri, 17 Feb 2017, Vikas Shivappa wrote: Subject: x86/intel_rdt: schemata file support for MBA prepare I have no idea what MBA prepare is. Is that yet another variant aside of MBE? Add support to introduce generic APIs for control validation

Re: [PATCH v7 00/13] mmc: Add support to Marvell Xenon SD Host Controller

On Thu, Mar 30, 2017 at 05:22:52PM +0200, Gregory CLEMENT wrote: > - Remove parse of child node mmc-card. Wait for a better solution. So for mcbin, I have: _sdhci0 { bus-width = <8>; marvell,xenon-emmc; marvell,xenon-phy-type = "emmc 5.1 phy"; /* * Not

Re: [PATCH v7 00/13] mmc: Add support to Marvell Xenon SD Host Controller

On Thu, Mar 30, 2017 at 05:22:52PM +0200, Gregory CLEMENT wrote: > - Remove parse of child node mmc-card. Wait for a better solution. So for mcbin, I have: _sdhci0 { bus-width = <8>; marvell,xenon-emmc; marvell,xenon-phy-type = "emmc 5.1 phy"; /* * Not

Re: [PATCH 5/5] x86/intel_rdt: hotcpu updates for RDT

On Wed, 1 Mar 2017, Thomas Gleixner wrote: WARN_ON(c->x86_cache_occ_scale != cqm_l3_scale); @@ -1585,12 +1580,17 @@ static int intel_cqm_cpu_starting(unsigned int cpu) static int intel_cqm_cpu_exit(unsigned int cpu) { + struct intel_pqr_state *state = _cpu(pqr_state, cpu);

Re: [PATCH 5/5] x86/intel_rdt: hotcpu updates for RDT

On Wed, 1 Mar 2017, Thomas Gleixner wrote: WARN_ON(c->x86_cache_occ_scale != cqm_l3_scale); @@ -1585,12 +1580,17 @@ static int intel_cqm_cpu_starting(unsigned int cpu) static int intel_cqm_cpu_exit(unsigned int cpu) { + struct intel_pqr_state *state = _cpu(pqr_state, cpu);

[PATCH] iio: gyro: adis16060: Change the function's name

Change the name of function from adis16060_spi_write_than_read() to adis16060_spi_write_then_read(). change "than" to "then" as its time depended. --- drivers/staging/iio/gyro/adis16060_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] iio: gyro: adis16060: Change the function's name

Change the name of function from adis16060_spi_write_than_read() to adis16060_spi_write_then_read(). change "than" to "then" as its time depended. --- drivers/staging/iio/gyro/adis16060_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 11:35 AM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:23 AM, Andy Lutomirski wrote: >> On Thu, Mar 30, 2017 at 10:46 AM, Linus Torvalds >> wrote: >>> >>> We *really* shouldn't

Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 11:35 AM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:23 AM, Andy Lutomirski wrote: >> On Thu, Mar 30, 2017 at 10:46 AM, Linus Torvalds >> wrote: >>> >>> We *really* shouldn't sign-extend that value if the debugger ends up >>> updating the pointer (or maybe the

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:54 AM, Al Viro wrote: > > Not even that - again, it will happily trigger page faults unless the > caller disables those. __copy_from_user_I_know_what_I_am_doing()? That's a horrible name. Everybody always thinks they know what they are doing.

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:54 AM, Al Viro wrote: > > Not even that - again, it will happily trigger page faults unless the > caller disables those. __copy_from_user_I_know_what_I_am_doing()? That's a horrible name. Everybody always thinks they know what they are doing. There's a reason I

Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash

Hi Guochun, Le 30/03/2017 à 10:23, Guochun Mao a écrit : > when nor's size larger than 16MByte, nor and controller should > enter 4Byte mode simultaneously. > > Signed-off-by: Guochun Mao > --- > drivers/mtd/spi-nor/mtk-quadspi.c |7 +++ > 1 file changed, 7

Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash

Hi Guochun, Le 30/03/2017 à 10:23, Guochun Mao a écrit : > when nor's size larger than 16MByte, nor and controller should > enter 4Byte mode simultaneously. > > Signed-off-by: Guochun Mao > --- > drivers/mtd/spi-nor/mtk-quadspi.c |7 +++ > 1 file changed, 7 insertions(+) > > diff

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:48 AM, Al Viro wrote: > > This is not going into the tree - it's just a "let's check your > theory about might_fault() overhead being the source of slowdown > you are seeing" quick-and-dirty patch. Note that for cached hdparm reads, I suspect a

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 11:48 AM, Al Viro wrote: > > This is not going into the tree - it's just a "let's check your > theory about might_fault() overhead being the source of slowdown > you are seeing" quick-and-dirty patch. Note that for cached hdparm reads, I suspect a *much* bigger effects

Re: [PATCH 4.9 00/16] 4.9.20-stable review

On 03/30/2017 04:15 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.20 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/16] 4.9.20-stable review

On 03/30/2017 04:15 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.20 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.10 00/17] 4.10.8-stable review

On 03/30/2017 04:00 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.8 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.10 00/17] 4.10.8-stable review

On 03/30/2017 04:00 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.8 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 07:48:24PM +0100, Al Viro wrote: > BTW, ..._inatomic is a very unfortunate name, IMO - it's *not* safe > to use in atomic contexts as-is, to start with; the caller needs to take > care of pagefault_disable(). If anything, __copy_from_user_nofault() would > probably be

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 07:48:24PM +0100, Al Viro wrote: > BTW, ..._inatomic is a very unfortunate name, IMO - it's *not* safe > to use in atomic contexts as-is, to start with; the caller needs to take > care of pagefault_disable(). If anything, __copy_from_user_nofault() would > probably be

Re: [PATCH 4.4 00/14] 4.4.59-stable review

On 03/30/2017 03:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.59 release. > There are 14 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/14] 4.4.59-stable review

On 03/30/2017 03:58 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.59 release. > There are 14 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: Apparent backward time travel in timestamps on file creation

On Thu, Mar 30, 2017 at 10:30 AM, David Howells wrote: > Hi Thomas, John, > > I've been writing a testcase for xfstests to test statx. However, it's turned > up what I think is a bug in the kernel's time-tracking system. If I do: > > date +%s.%N > touch foo

Re: Apparent backward time travel in timestamps on file creation

On Thu, Mar 30, 2017 at 10:30 AM, David Howells wrote: > Hi Thomas, John, > > I've been writing a testcase for xfstests to test statx. However, it's turned > up what I think is a bug in the kernel's time-tracking system. If I do: > > date +%s.%N > touch foo >

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 10:18:23AM -0700, Linus Torvalds wrote: > This is all going in the wrong direction entirely. This is not going into the tree - it's just a "let's check your theory about might_fault() overhead being the source of slowdown you are seeing" quick-and-dirty patch. Speaking

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On Thu, Mar 30, 2017 at 10:18:23AM -0700, Linus Torvalds wrote: > This is all going in the wrong direction entirely. This is not going into the tree - it's just a "let's check your theory about might_fault() overhead being the source of slowdown you are seeing" quick-and-dirty patch. Speaking

Re: [PATCH net] openvswitch: Fix ovs_flow_key_update()

On Thu, 30 Mar 2017 11:39:35 -0700, Yi-Hung Wei wrote: > If we invalidate a flow key of a L3 packet, the flow's mac_proto is like this > (MAC_PROTO_NONE | SW_FLOW_KEY_INVALID), then key_extract() will > process the link layer of this L3 packet since mac_proto !=MAC_PROTO_NONE? > > In this case,

Re: [PATCH net] openvswitch: Fix ovs_flow_key_update()

On Thu, 30 Mar 2017 11:39:35 -0700, Yi-Hung Wei wrote: > If we invalidate a flow key of a L3 packet, the flow's mac_proto is like this > (MAC_PROTO_NONE | SW_FLOW_KEY_INVALID), then key_extract() will > process the link layer of this L3 packet since mac_proto !=MAC_PROTO_NONE? > > In this case,

Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote: > > That would be nice, but still won't work as we blindly copy f_flags > into F_GETFL, not even masking our internal FMODE_ bits. Ok, *that* is just silly of us, and we could try to just fix, and even backport. There's no

Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote: > > That would be nice, but still won't work as we blindly copy f_flags > into F_GETFL, not even masking our internal FMODE_ bits. Ok, *that* is just silly of us, and we could try to just fix, and even backport. There's no possible

Re: [PATCH 4.4 48/76] libceph: force GFP_NOIO for socket allocations

On Thu 30-03-17 19:19:59, Ilya Dryomov wrote: > On Thu, Mar 30, 2017 at 6:12 PM, Michal Hocko wrote: > > On Thu 30-03-17 17:06:51, Ilya Dryomov wrote: > > [...] > >> > But if the allocation is stuck then the holder of the lock cannot make > >> > a forward progress and it is

Re: [PATCH 4.4 48/76] libceph: force GFP_NOIO for socket allocations

On Thu 30-03-17 19:19:59, Ilya Dryomov wrote: > On Thu, Mar 30, 2017 at 6:12 PM, Michal Hocko wrote: > > On Thu 30-03-17 17:06:51, Ilya Dryomov wrote: > > [...] > >> > But if the allocation is stuck then the holder of the lock cannot make > >> > a forward progress and it is effectivelly

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Fri, Mar 31, 2017 at 12:02 AM, Jonathan Cameron wrote: > On 28/03/17 19:37, Alison Schofield wrote: >> On Tue, Mar 28, 2017 at 10:55:17PM +0530, SIMRAN SINGHAL wrote: >>> On Fri, Mar 24, 2017 at 12:51 AM, Alison Schofield >>> wrote: On Fri, Mar

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Fri, Mar 31, 2017 at 12:02 AM, Jonathan Cameron wrote: > On 28/03/17 19:37, Alison Schofield wrote: >> On Tue, Mar 28, 2017 at 10:55:17PM +0530, SIMRAN SINGHAL wrote: >>> On Fri, Mar 24, 2017 at 12:51 AM, Alison Schofield >>> wrote: On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran

<    1   2   3   4   5   6   7   8   9   10   >