[GIT PULL] two more s390 bug fixes for 4.17
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:
Two bug fixes for 4.17
* A missing -msoft-float for the compile of the kexec purgatory
* A fix for the dasd driver to avoid the double use of a field in
the 'struct request'
Philipp Rudo (1):
s390/purgatory: Fix endless interrupt loop
Sebastian Ott (1):
s390/dasd: use blk_mq_rq_from_pdu for per request data
arch/s390/purgatory/Makefile | 2 +-
drivers/s390/block/dasd.c| 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/s390/purgatory/Makefile b/arch/s390/purgatory/Makefile
index e9525bc..1ace023 100644
--- a/arch/s390/purgatory/Makefile
+++ b/arch/s390/purgatory/Makefile
@@ -21,7 +21,7 @@ LDFLAGS_purgatory.ro += -z nodefaultlib
KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes
KBUILD_CFLAGS += -Wno-pointer-sign -Wno-sign-compare
KBUILD_CFLAGS += -fno-zero-initialized-in-bss -fno-builtin -ffreestanding
-KBUILD_CFLAGS += -c -MD -Os -m64
+KBUILD_CFLAGS += -c -MD -Os -m64 -msoft-float
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 04143c0..02c03e4 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -3034,7 +3034,8 @@ static blk_status_t do_dasd_request(struct blk_mq_hw_ctx
*hctx,
cqr->callback_data = req;
cqr->status = DASD_CQR_FILLED;
cqr->dq = dq;
- req->completion_data = cqr;
+ *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr;
+
blk_mq_start_request(req);
spin_lock(>queue_lock);
list_add_tail(>blocklist, >ccw_queue);
@@ -3058,12 +3059,13 @@ static blk_status_t do_dasd_request(struct
blk_mq_hw_ctx *hctx,
*/
enum blk_eh_timer_return dasd_times_out(struct request *req, bool reserved)
{
- struct dasd_ccw_req *cqr = req->completion_data;
struct dasd_block *block = req->q->queuedata;
struct dasd_device *device;
+ struct dasd_ccw_req *cqr;
unsigned long flags;
int rc = 0;
+ cqr = *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req));
if (!cqr)
return BLK_EH_NOT_HANDLED;
@@ -3169,6 +3171,7 @@ static int dasd_alloc_queue(struct dasd_block *block)
int rc;
block->tag_set.ops = _mq_ops;
+ block->tag_set.cmd_size = sizeof(struct dasd_ccw_req *);
block->tag_set.nr_hw_queues = DASD_NR_HW_QUEUES;
block->tag_set.queue_depth = DASD_MAX_LCU_DEV * DASD_REQ_PER_DEV;
block->tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
[GIT PULL] two more s390 bug fixes for 4.17
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:
Two bug fixes for 4.17
* A missing -msoft-float for the compile of the kexec purgatory
* A fix for the dasd driver to avoid the double use of a field in
the 'struct request'
Philipp Rudo (1):
s390/purgatory: Fix endless interrupt loop
Sebastian Ott (1):
s390/dasd: use blk_mq_rq_from_pdu for per request data
arch/s390/purgatory/Makefile | 2 +-
drivers/s390/block/dasd.c| 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/s390/purgatory/Makefile b/arch/s390/purgatory/Makefile
index e9525bc..1ace023 100644
--- a/arch/s390/purgatory/Makefile
+++ b/arch/s390/purgatory/Makefile
@@ -21,7 +21,7 @@ LDFLAGS_purgatory.ro += -z nodefaultlib
KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes
KBUILD_CFLAGS += -Wno-pointer-sign -Wno-sign-compare
KBUILD_CFLAGS += -fno-zero-initialized-in-bss -fno-builtin -ffreestanding
-KBUILD_CFLAGS += -c -MD -Os -m64
+KBUILD_CFLAGS += -c -MD -Os -m64 -msoft-float
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 04143c0..02c03e4 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -3034,7 +3034,8 @@ static blk_status_t do_dasd_request(struct blk_mq_hw_ctx
*hctx,
cqr->callback_data = req;
cqr->status = DASD_CQR_FILLED;
cqr->dq = dq;
- req->completion_data = cqr;
+ *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr;
+
blk_mq_start_request(req);
spin_lock(>queue_lock);
list_add_tail(>blocklist, >ccw_queue);
@@ -3058,12 +3059,13 @@ static blk_status_t do_dasd_request(struct
blk_mq_hw_ctx *hctx,
*/
enum blk_eh_timer_return dasd_times_out(struct request *req, bool reserved)
{
- struct dasd_ccw_req *cqr = req->completion_data;
struct dasd_block *block = req->q->queuedata;
struct dasd_device *device;
+ struct dasd_ccw_req *cqr;
unsigned long flags;
int rc = 0;
+ cqr = *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req));
if (!cqr)
return BLK_EH_NOT_HANDLED;
@@ -3169,6 +3171,7 @@ static int dasd_alloc_queue(struct dasd_block *block)
int rc;
block->tag_set.ops = _mq_ops;
+ block->tag_set.cmd_size = sizeof(struct dasd_ccw_req *);
block->tag_set.nr_hw_queues = DASD_NR_HW_QUEUES;
block->tag_set.queue_depth = DASD_MAX_LCU_DEV * DASD_REQ_PER_DEV;
block->tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
Re: [reset-control] How to initialize hardware state with the shared reset line?
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > :
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > >Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > >Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > >reset-controller {
>>> > > >
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > >}
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the
>>> > forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has
>>> > been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the
Re: [reset-control] How to initialize hardware state with the shared reset line?
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > :
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > >Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > >Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > >reset-controller {
>>> > > >
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > >}
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the
>>> > forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has
>>> > been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the
Re: [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
* nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming
> ---
> arch/x86/mm/init_32.c | 2 ++
> arch/x86/mm/init_64.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c893c6a..121c567 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
> if (__supported_pte_mask & _PAGE_NX)
> debug_checkwx();
> }
> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0a40060..1b7a1a7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>*/
> pti_clone_kernel_text();
> }
> +#endif
NAK, this is very ugly and the changelog doesn't appear to be true: the build
warning does not trigger in the default build, correct?
Thanks,
Ingo
Re: [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
* nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming
> ---
> arch/x86/mm/init_32.c | 2 ++
> arch/x86/mm/init_64.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c893c6a..121c567 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
> if (__supported_pte_mask & _PAGE_NX)
> debug_checkwx();
> }
> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0a40060..1b7a1a7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>*/
> pti_clone_kernel_text();
> }
> +#endif
NAK, this is very ugly and the changelog doesn't appear to be true: the build
warning does not trigger in the default build, correct?
Thanks,
Ingo
Re: [GIT PULL rcu/next] Additional RCU commit for 4.18
* Paul E. McKenney wrote: > Hello, Ingo, > > This additional v4.18 pull request contains a single commit that fell > through the cracks: > > 1.Provide early rcu_cpu_starting() callback for the benefit of the > x86/mtrr code, which needs RCU to be available on incoming CPUs > earlier than has been the case in the past. > > http://lkml.kernel.org/r/20180525191802.ga7...@linux.vnet.ibm.com > > All of these changes have been subjected to 0day Test Robot and -next > testing, and are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > for-mingo > > for you to fetch changes up to f64c6013a2029316ea552f99823d116ee5f5f955: > > rcu/x86: Provide early rcu_cpu_starting() callback (2018-05-22 16:12:26 > -0700) > > > Peter Zijlstra (1): > rcu/x86: Provide early rcu_cpu_starting() callback > > arch/x86/kernel/cpu/mtrr/main.c | 4 > include/linux/rcupdate.h| 1 - > include/linux/rcutiny.h | 1 + > include/linux/rcutree.h | 1 + > kernel/rcu/tree.c | 9 + > 5 files changed, 15 insertions(+), 1 deletion(-) Pulled, thanks a lot Paul! Ingo
Re: [GIT PULL rcu/next] Additional RCU commit for 4.18
* Paul E. McKenney wrote: > Hello, Ingo, > > This additional v4.18 pull request contains a single commit that fell > through the cracks: > > 1.Provide early rcu_cpu_starting() callback for the benefit of the > x86/mtrr code, which needs RCU to be available on incoming CPUs > earlier than has been the case in the past. > > http://lkml.kernel.org/r/20180525191802.ga7...@linux.vnet.ibm.com > > All of these changes have been subjected to 0day Test Robot and -next > testing, and are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > for-mingo > > for you to fetch changes up to f64c6013a2029316ea552f99823d116ee5f5f955: > > rcu/x86: Provide early rcu_cpu_starting() callback (2018-05-22 16:12:26 > -0700) > > > Peter Zijlstra (1): > rcu/x86: Provide early rcu_cpu_starting() callback > > arch/x86/kernel/cpu/mtrr/main.c | 4 > include/linux/rcupdate.h| 1 - > include/linux/rcutiny.h | 1 + > include/linux/rcutree.h | 1 + > kernel/rcu/tree.c | 9 + > 5 files changed, 15 insertions(+), 1 deletion(-) Pulled, thanks a lot Paul! Ingo
Re: [PATCH 3.18 093/185] microblaze: switch to NO_BOOTMEM
On 29.5.2018 16:34, Rob Herring wrote: > On Mon, May 28, 2018 at 5:02 AM, Greg Kroah-Hartman > wrote: >> 3.18-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: Rob Herring >> >> [ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542 ] >> >> Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc() >> doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM. > > Unless Michal feels differently, I don't think this should go in > stable. The DT change that broke microblaze is only in 4.16 . yes. It is not needed. Thanks, Michal
Re: [PATCH 3.18 093/185] microblaze: switch to NO_BOOTMEM
On 29.5.2018 16:34, Rob Herring wrote: > On Mon, May 28, 2018 at 5:02 AM, Greg Kroah-Hartman > wrote: >> 3.18-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: Rob Herring >> >> [ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542 ] >> >> Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc() >> doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM. > > Unless Michal feels differently, I don't think this should go in > stable. The DT change that broke microblaze is only in 4.16 . yes. It is not needed. Thanks, Michal
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> > On 2018년 05월 09일 08:17, John Stultz wrote:
> >> Hey folks,
> >> I wanted to bring up an issue we've recently tripped over, which was
> >> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
> >> devfreq(X) for sysfs").
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
> >>
> >> That patch replaced paths like:
> >>/sys/class/devfreq/ddr_devfreq/min_freq
> >> and
> >> /sys/class/devfreq/e82c.mali/min_freq
> >>
> >> With
> >> /sys/class/devfreq/devfreq(0)/min_freq
> >> and
> >> /sys/class/devfreq/devfreq(1)/min_freq
> >>
> >>
> >> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
> >> on).
> >
> > Firstly, I'm sorry to make some problem on userland.
> >
> >>
> >> I wanted to try to ask to understand more about the rational for this
> >> patch, as it doesn't make much sense to me, particularly as now it is
> >> less obvious as to which path is for which device - and more
> >> worrisome it could change depending on initialization order.
> >
> > Some linux framework used the their own prefix under "/sys/class/"
> > for device such as input/pwm/hwmon/regulator and so on.
> > (But, some linux framework used the device name directly without any
> > changes)
> >
> > I thought that devfreq better to use use the consistent name.
> > If user wanted to access the specific device with device name,
> > the user can access the path of '/sys/devices/platform/...'.
> >
> > [Example on Exynos5433-based TM2 board]
> > root@localhost:~# ls -al /sys/class/devfreq
> > total 0
> > drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> > drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> > ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> > ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> > (skip)
> >
> > - User can access the devfreq device with specific device name.
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> > /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> > available_frequencies devicemin_freq subsystemuevent
> > available_governorsgovernor polling_interval target_freq
> > cur_freq max_freq power trans_stat
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> > min_freq
> > 16000
> >
>
> Sorry to not get back to you sooner on this. Was on vacation then this
> discussion got buried in my inbox.
>
> I do agree that it the consistency with other subsystems is an
> improvement, but it still doesn't help our situation that userspace
> applications can't consistently work between kernel versions, as even
> if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> path rather then the /sys/class/devfreq/ path, in older kernels the
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
Ick, that's not ok. The sys/class/ path should always work for old and
new. If not, it's broken and should be reverted.
And it seems like it still works, just that the "names" are now
different in the class path, of the device, right? And that should be
fine, what is breaking when a device name changes?
> > But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> > doesn't have the 'name' attribute. So, the user cannot find the required
> > device. It is my mistake. I'll add the 'name' attribute as following:
> > - /sys/class/devfreq/devfreqX/name
>
> I agree that would be an improvement.
>
> >> Unfortunately, this wasn't noticed very quickly, as the patch has been
> >> upstream now for some time. But I wanted to better understand why
> >> this change was made, and see if we might consider reverting it, or
> >> alternatively consider provide multiple sysfs links (both dev_name and
> >> devfreq(N)) so that we can preserve compatibility?
> >
> > Unfortunately, there are no frameworks which provide the both dev_name and
> > [defined prefix](N) link under /sys/class/. I'm not sure this way.
> >
> > As you comment, devfreq(number) is not fixed as the initialization order.
> > After adding the 'name' attribute, the user can find the specific device.
> >
> > How about using the 'name' attribute to find the device
> > after adding new 'name' attribute when access device through /sys/class?
>
> I agree we need a name attribute so folks can tell the difference
> between devices.
>
> I'm also not too much of a stickler that the old ABI broke, as long as
> we have some solution that works across kernels. So I'd request that
> you at least make older -stable kernels (4.4 and 4.9) behavior
> consistent with upstream.
No, I don't want to backport api changes
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> > On 2018년 05월 09일 08:17, John Stultz wrote:
> >> Hey folks,
> >> I wanted to bring up an issue we've recently tripped over, which was
> >> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
> >> devfreq(X) for sysfs").
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
> >>
> >> That patch replaced paths like:
> >>/sys/class/devfreq/ddr_devfreq/min_freq
> >> and
> >> /sys/class/devfreq/e82c.mali/min_freq
> >>
> >> With
> >> /sys/class/devfreq/devfreq(0)/min_freq
> >> and
> >> /sys/class/devfreq/devfreq(1)/min_freq
> >>
> >>
> >> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
> >> on).
> >
> > Firstly, I'm sorry to make some problem on userland.
> >
> >>
> >> I wanted to try to ask to understand more about the rational for this
> >> patch, as it doesn't make much sense to me, particularly as now it is
> >> less obvious as to which path is for which device - and more
> >> worrisome it could change depending on initialization order.
> >
> > Some linux framework used the their own prefix under "/sys/class/"
> > for device such as input/pwm/hwmon/regulator and so on.
> > (But, some linux framework used the device name directly without any
> > changes)
> >
> > I thought that devfreq better to use use the consistent name.
> > If user wanted to access the specific device with device name,
> > the user can access the path of '/sys/devices/platform/...'.
> >
> > [Example on Exynos5433-based TM2 board]
> > root@localhost:~# ls -al /sys/class/devfreq
> > total 0
> > drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> > drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> > ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> > lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> > ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> > (skip)
> >
> > - User can access the devfreq device with specific device name.
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> > /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> > available_frequencies devicemin_freq subsystemuevent
> > available_governorsgovernor polling_interval target_freq
> > cur_freq max_freq power trans_stat
> >
> > root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> > min_freq
> > 16000
> >
>
> Sorry to not get back to you sooner on this. Was on vacation then this
> discussion got buried in my inbox.
>
> I do agree that it the consistency with other subsystems is an
> improvement, but it still doesn't help our situation that userspace
> applications can't consistently work between kernel versions, as even
> if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
> path rather then the /sys/class/devfreq/ path, in older kernels the
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
Ick, that's not ok. The sys/class/ path should always work for old and
new. If not, it's broken and should be reverted.
And it seems like it still works, just that the "names" are now
different in the class path, of the device, right? And that should be
fine, what is breaking when a device name changes?
> > But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> > doesn't have the 'name' attribute. So, the user cannot find the required
> > device. It is my mistake. I'll add the 'name' attribute as following:
> > - /sys/class/devfreq/devfreqX/name
>
> I agree that would be an improvement.
>
> >> Unfortunately, this wasn't noticed very quickly, as the patch has been
> >> upstream now for some time. But I wanted to better understand why
> >> this change was made, and see if we might consider reverting it, or
> >> alternatively consider provide multiple sysfs links (both dev_name and
> >> devfreq(N)) so that we can preserve compatibility?
> >
> > Unfortunately, there are no frameworks which provide the both dev_name and
> > [defined prefix](N) link under /sys/class/. I'm not sure this way.
> >
> > As you comment, devfreq(number) is not fixed as the initialization order.
> > After adding the 'name' attribute, the user can find the specific device.
> >
> > How about using the 'name' attribute to find the device
> > after adding new 'name' attribute when access device through /sys/class?
>
> I agree we need a name attribute so folks can tell the difference
> between devices.
>
> I'm also not too much of a stickler that the old ABI broke, as long as
> we have some solution that works across kernels. So I'd request that
> you at least make older -stable kernels (4.4 and 4.9) behavior
> consistent with upstream.
No, I don't want to backport api changes
Re: [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
Hi, On Tue, May 22, 2018 at 7:43 PM, David Collins wrote: > + * @ever_enabled: Boolean indicating that the regulator has been > + * explicitly enabled at least once. Voltage > + * requests should be cached when this flag is > not > + * set. Do you really need this extra boolean? Can't you just check if "enabled" is still "-EINVAL"? If it is then you don't pass the voltage along. ...this would mean that you'd also need to send the voltage vote when the regulator core tries to disable unused regulators at the end of bootup, but that should be OK right? If we never touched a regulator anywhere at probe time and we're about to vote to disable it, we know there's nobody requiring it to still be on. We can vote for the voltage now without fear of messing up a vote that the BIOS left in place. In theory this should also allow you to assert your vote about the voltage of a regulator that has never been enabled, which (if I understand correctly) you consider to be a feature. --- Other than that comment, everything else here looks good to go if Mark is good with it. As per the previous threads there are some things that I don't like a ton, but I feel it is between you and Mark to decide if you're good with it. A summary of those issues are: 1. I still believe that when we disable a regulator in Linux we should tell RPMh that we vote for the lowest voltage. ...but if Mark is happy with the way the driver works now I won't push it. 2. As per my comments in the bindings patch, I still believe that "qcom,drms-mode-max-microamps" belongs in the core. Again, up to Mark. 3. As per my comments in the bindings patch, I still believe that we're just adding lots of noise to the DT most of the time by specifying both "qcom,regulator-drms-modes" and "regulator-allowed-modes". Again, up to Mark. -Doug
Re: [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
Hi, On Tue, May 22, 2018 at 7:43 PM, David Collins wrote: > + * @ever_enabled: Boolean indicating that the regulator has been > + * explicitly enabled at least once. Voltage > + * requests should be cached when this flag is > not > + * set. Do you really need this extra boolean? Can't you just check if "enabled" is still "-EINVAL"? If it is then you don't pass the voltage along. ...this would mean that you'd also need to send the voltage vote when the regulator core tries to disable unused regulators at the end of bootup, but that should be OK right? If we never touched a regulator anywhere at probe time and we're about to vote to disable it, we know there's nobody requiring it to still be on. We can vote for the voltage now without fear of messing up a vote that the BIOS left in place. In theory this should also allow you to assert your vote about the voltage of a regulator that has never been enabled, which (if I understand correctly) you consider to be a feature. --- Other than that comment, everything else here looks good to go if Mark is good with it. As per the previous threads there are some things that I don't like a ton, but I feel it is between you and Mark to decide if you're good with it. A summary of those issues are: 1. I still believe that when we disable a regulator in Linux we should tell RPMh that we vote for the lowest voltage. ...but if Mark is happy with the way the driver works now I won't push it. 2. As per my comments in the bindings patch, I still believe that "qcom,drms-mode-max-microamps" belongs in the core. Again, up to Mark. 3. As per my comments in the bindings patch, I still believe that we're just adding lots of noise to the DT most of the time by specifying both "qcom,regulator-drms-modes" and "regulator-allowed-modes". Again, up to Mark. -Doug
Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi, On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote: > On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote: >> On Wed, May 23, 2018 at 8:40 AM, Mark Brown wrote: > >> > It's got to be valid to think about the voltage of a disabled regulator >> > since drivers want to be able make sure that the regulator gets enabled >> > with a sensible config. With most hardware this is really easy since >> > you can just look at the status reported by the hardware but the RPM >> > makes this hard since there's so much write only stuff in there. > >> I should be more clear. Certainly it should be valid to set the >> voltage before enabling it so, as you said, the regulator turns on at >> the right voltage. I'm saying that it's weird (to me) to expect that >> setting the voltage for a regulator that a client thinks is disabled >> will affect any real voltages in the system until the regulator is >> enabled. In RPMh apparently setting a voltage of a regulator you >> think is disabled can affect the regulator output if another client >> (unbeknownst to you) happens to have it enabled. > > Yes, that's definitely not what's expected but it's unfortunately what > the firmware chose to implement so we may well be stuck with it > unfortunately. We're not really stuck with it if we do what I was suggesting. I was suggesting that every time we disable the regulator in Linux we have Linux vote for the lowest voltage it's comfortable with. Linux keeps track of the true voltage that the driver wants and will always change its vote back to that before enabling. Thus (assuming Linux is OK with 1.2 V - 1.4 V for a rail): Modem: want 1.3 V and enabled. => Modem votes for 1.3 V => Modem votes for enabled. => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want 1.4 V and enabled. => Linux votes for 1.4 V => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V Linux: want disabled => Linux votes for disabled => Linux votes for 1.2 V (keeps 1.4 V in local var) => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want enabled => Linux votes for 1.4 V (from local var) => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V ...but I'll leave it to you if you think this is a big deal. If you're happy with how David's driver works without my suggestion then I won't push it. -Doug
Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi, On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote: > On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote: >> On Wed, May 23, 2018 at 8:40 AM, Mark Brown wrote: > >> > It's got to be valid to think about the voltage of a disabled regulator >> > since drivers want to be able make sure that the regulator gets enabled >> > with a sensible config. With most hardware this is really easy since >> > you can just look at the status reported by the hardware but the RPM >> > makes this hard since there's so much write only stuff in there. > >> I should be more clear. Certainly it should be valid to set the >> voltage before enabling it so, as you said, the regulator turns on at >> the right voltage. I'm saying that it's weird (to me) to expect that >> setting the voltage for a regulator that a client thinks is disabled >> will affect any real voltages in the system until the regulator is >> enabled. In RPMh apparently setting a voltage of a regulator you >> think is disabled can affect the regulator output if another client >> (unbeknownst to you) happens to have it enabled. > > Yes, that's definitely not what's expected but it's unfortunately what > the firmware chose to implement so we may well be stuck with it > unfortunately. We're not really stuck with it if we do what I was suggesting. I was suggesting that every time we disable the regulator in Linux we have Linux vote for the lowest voltage it's comfortable with. Linux keeps track of the true voltage that the driver wants and will always change its vote back to that before enabling. Thus (assuming Linux is OK with 1.2 V - 1.4 V for a rail): Modem: want 1.3 V and enabled. => Modem votes for 1.3 V => Modem votes for enabled. => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want 1.4 V and enabled. => Linux votes for 1.4 V => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V Linux: want disabled => Linux votes for disabled => Linux votes for 1.2 V (keeps 1.4 V in local var) => At least one vote for enabled? Yes => Highest voltage vote: 1.3V => True output: 1.3V Linux: want enabled => Linux votes for 1.4 V (from local var) => Linux votes for enabled => At least one vote for enabled? Yes => Highest voltage vote: 1.4V => True output: 1.4V ...but I'll leave it to you if you think this is a big deal. If you're happy with how David's driver works without my suggestion then I won't push it. -Doug
Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> +
> +Examples
> +
> +
> +#include
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <204>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + regulator-allowed-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <1 100>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> +
> +Examples
> +
> +
> +#include
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <204>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + regulator-allowed-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> ++RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <1 100>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
[PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find reason that there is a newly added region.
If a newly added region invoke kernel panic, it will be helpful. This
patch records if there is count overflow or range overlap, and invoke
panic if that case.
These are test example based on v4.9.
Case 1 - out of region count
<3>[0.00] [0:swapper:0] OF: reserved mem: not enough space
all defined regions.
<0>[1.688695] [6: swapper/0:1] Kernel panic - not syncing:
overflow on reserved memory, check the latest change
<4>[1.688743] [6: swapper/0:1] CPU: 6 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #10
<4>[1.688836] [6: swapper/0:1] Call trace:
<4>[1.688869] [6: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[1.688913] [6: swapper/0:1] []
show_stack+0x18/0x28
<4>[1.688958] [6: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[1.689001] [6: swapper/0:1] []
panic+0x1e0/0x404
<4>[1.689046] [6: swapper/0:1] []
check_reserved_mem+0x40/0x50
<4>[1.689091] [6: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[1.689138] [6: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[1.689187] [6: swapper/0:1] []
kernel_init+0x18/0x144
<4>[1.689229] [6: swapper/0:1] []
ret_from_fork+0x10/0x40
Case 2 - overlapped region
<3>[0.00] [0:swapper:0] OF: reserved mem: OVERLAP DETECTED!
<0>[2.309331] [2: swapper/0:1] Kernel panic - not syncing:
reserved memory overlap, check the latest change
<4>[2.309398] [2: swapper/0:1] CPU: 2 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #14
<4>[2.309508] [2: swapper/0:1] Call trace:
<4>[2.309546] [2: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[2.309599] [2: swapper/0:1] []
show_stack+0x18/0x28
<4>[2.309652] [2: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[2.309701] [2: swapper/0:1] []
panic+0x1e0/0x404
<4>[2.309751] [2: swapper/0:1] []
check_reserved_mem+0x4c/0x50
<4>[2.309802] [2: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[2.309856] [2: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[2.309913] [2: swapper/0:1] []
kernel_init+0x18/0x144
<4>[2.309961] [2: swapper/0:1] []
ret_from_fork+0x10/0x40
Signed-off-by: Jaewon Kim
---
drivers/of/of_reserved_mem.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 9a4f4246231d..e97d5c5dcc9a 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -65,6 +65,7 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
#endif
+static bool rmem_overflow;
/**
* res_mem_save_node() - save fdt node for second pass initialization
*/
@@ -75,6 +76,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node,
const char *uname,
if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
pr_err("not enough space all defined regions.\n");
+ rmem_overflow = true;
return;
}
@@ -221,6 +223,7 @@ static int __init __rmem_cmp(const void *a, const void *b)
return 0;
}
+static bool rmem_overlap;
static void __init __rmem_check_for_overlap(void)
{
int i;
@@ -245,6 +248,7 @@ static void __init __rmem_check_for_overlap(void)
pr_err("OVERLAP DETECTED!\n%s (%pa--%pa) overlaps with
%s (%pa--%pa)\n",
this->name, >base, _end,
next->name, >base, _end);
+ rmem_overlap = true;
}
}
}
@@ -419,3 +423,13 @@ struct reserved_mem *of_reserved_mem_lookup(struct
device_node *np)
return NULL;
}
EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
+
+static int check_reserved_mem(void)
+{
+ if (rmem_overflow)
+ panic("overflow on reserved memory, check the latest change");
+ if (rmem_overlap)
+ panic("overlap on reserved memory, check the latest change");
+ return 0;
+}
+late_initcall(check_reserved_mem);
--
2.13.0
[PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find reason that there is a newly added region.
If a newly added region invoke kernel panic, it will be helpful. This
patch records if there is count overflow or range overlap, and invoke
panic if that case.
These are test example based on v4.9.
Case 1 - out of region count
<3>[0.00] [0:swapper:0] OF: reserved mem: not enough space
all defined regions.
<0>[1.688695] [6: swapper/0:1] Kernel panic - not syncing:
overflow on reserved memory, check the latest change
<4>[1.688743] [6: swapper/0:1] CPU: 6 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #10
<4>[1.688836] [6: swapper/0:1] Call trace:
<4>[1.688869] [6: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[1.688913] [6: swapper/0:1] []
show_stack+0x18/0x28
<4>[1.688958] [6: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[1.689001] [6: swapper/0:1] []
panic+0x1e0/0x404
<4>[1.689046] [6: swapper/0:1] []
check_reserved_mem+0x40/0x50
<4>[1.689091] [6: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[1.689138] [6: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[1.689187] [6: swapper/0:1] []
kernel_init+0x18/0x144
<4>[1.689229] [6: swapper/0:1] []
ret_from_fork+0x10/0x40
Case 2 - overlapped region
<3>[0.00] [0:swapper:0] OF: reserved mem: OVERLAP DETECTED!
<0>[2.309331] [2: swapper/0:1] Kernel panic - not syncing:
reserved memory overlap, check the latest change
<4>[2.309398] [2: swapper/0:1] CPU: 2 PID: 1 Comm: swapper/0 Not
tainted 4.9.65+ #14
<4>[2.309508] [2: swapper/0:1] Call trace:
<4>[2.309546] [2: swapper/0:1] []
dump_backtrace+0x0/0x248
<4>[2.309599] [2: swapper/0:1] []
show_stack+0x18/0x28
<4>[2.309652] [2: swapper/0:1] []
dump_stack+0x98/0xc0
<4>[2.309701] [2: swapper/0:1] []
panic+0x1e0/0x404
<4>[2.309751] [2: swapper/0:1] []
check_reserved_mem+0x4c/0x50
<4>[2.309802] [2: swapper/0:1] []
do_one_initcall+0x54/0x214
<4>[2.309856] [2: swapper/0:1] []
kernel_init_freeable+0x198/0x24c
<4>[2.309913] [2: swapper/0:1] []
kernel_init+0x18/0x144
<4>[2.309961] [2: swapper/0:1] []
ret_from_fork+0x10/0x40
Signed-off-by: Jaewon Kim
---
drivers/of/of_reserved_mem.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 9a4f4246231d..e97d5c5dcc9a 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -65,6 +65,7 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
#endif
+static bool rmem_overflow;
/**
* res_mem_save_node() - save fdt node for second pass initialization
*/
@@ -75,6 +76,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node,
const char *uname,
if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
pr_err("not enough space all defined regions.\n");
+ rmem_overflow = true;
return;
}
@@ -221,6 +223,7 @@ static int __init __rmem_cmp(const void *a, const void *b)
return 0;
}
+static bool rmem_overlap;
static void __init __rmem_check_for_overlap(void)
{
int i;
@@ -245,6 +248,7 @@ static void __init __rmem_check_for_overlap(void)
pr_err("OVERLAP DETECTED!\n%s (%pa--%pa) overlaps with
%s (%pa--%pa)\n",
this->name, >base, _end,
next->name, >base, _end);
+ rmem_overlap = true;
}
}
}
@@ -419,3 +423,13 @@ struct reserved_mem *of_reserved_mem_lookup(struct
device_node *np)
return NULL;
}
EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
+
+static int check_reserved_mem(void)
+{
+ if (rmem_overflow)
+ panic("overflow on reserved memory, check the latest change");
+ if (rmem_overlap)
+ panic("overlap on reserved memory, check the latest change");
+ return 0;
+}
+late_initcall(check_reserved_mem);
--
2.13.0
Re: [PATCH] ext4: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this appropriately. See for example: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/e2p/ls.c#n436 GCC-8 may whine about it, but the whine is, in fact, not correct. It's making assumptions about all strings being null terminated, which is often, but not always, the case. Cheers, - Ted
Re: [PATCH] ext4: prefer strlcpy to strncpy
On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this appropriately. See for example: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/e2p/ls.c#n436 GCC-8 may whine about it, but the whine is, in fact, not correct. It's making assumptions about all strings being null terminated, which is often, but not always, the case. Cheers, - Ted
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> On 2018년 05월 09일 08:17, John Stultz wrote:
>> Hey folks,
>> I wanted to bring up an issue we've recently tripped over, which was
>> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> devfreq(X) for sysfs").
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
>>
>> That patch replaced paths like:
>>/sys/class/devfreq/ddr_devfreq/min_freq
>> and
>> /sys/class/devfreq/e82c.mali/min_freq
>>
>> With
>> /sys/class/devfreq/devfreq(0)/min_freq
>> and
>> /sys/class/devfreq/devfreq(1)/min_freq
>>
>>
>> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
>> on).
>
> Firstly, I'm sorry to make some problem on userland.
>
>>
>> I wanted to try to ask to understand more about the rational for this
>> patch, as it doesn't make much sense to me, particularly as now it is
>> less obvious as to which path is for which device - and more
>> worrisome it could change depending on initialization order.
>
> Some linux framework used the their own prefix under "/sys/class/"
> for device such as input/pwm/hwmon/regulator and so on.
> (But, some linux framework used the device name directly without any changes)
>
> I thought that devfreq better to use use the consistent name.
> If user wanted to access the specific device with device name,
> the user can access the path of '/sys/devices/platform/...'.
>
> [Example on Exynos5433-based TM2 board]
> root@localhost:~# ls -al /sys/class/devfreq
> total 0
> drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> (skip)
>
> - User can access the devfreq device with specific device name.
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> available_frequencies devicemin_freq subsystemuevent
> available_governorsgovernor polling_interval target_freq
> cur_freq max_freq power trans_stat
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> min_freq
> 16000
>
Sorry to not get back to you sooner on this. Was on vacation then this
discussion got buried in my inbox.
I do agree that it the consistency with other subsystems is an
improvement, but it still doesn't help our situation that userspace
applications can't consistently work between kernel versions, as even
if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
path rather then the /sys/class/devfreq/ path, in older kernels the
/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
> But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> doesn't have the 'name' attribute. So, the user cannot find the required
> device. It is my mistake. I'll add the 'name' attribute as following:
> - /sys/class/devfreq/devfreqX/name
I agree that would be an improvement.
>> Unfortunately, this wasn't noticed very quickly, as the patch has been
>> upstream now for some time. But I wanted to better understand why
>> this change was made, and see if we might consider reverting it, or
>> alternatively consider provide multiple sysfs links (both dev_name and
>> devfreq(N)) so that we can preserve compatibility?
>
> Unfortunately, there are no frameworks which provide the both dev_name and
> [defined prefix](N) link under /sys/class/. I'm not sure this way.
>
> As you comment, devfreq(number) is not fixed as the initialization order.
> After adding the 'name' attribute, the user can find the specific device.
>
> How about using the 'name' attribute to find the device
> after adding new 'name' attribute when access device through /sys/class?
I agree we need a name attribute so folks can tell the difference
between devices.
I'm also not too much of a stickler that the old ABI broke, as long as
we have some solution that works across kernels. So I'd request that
you at least make older -stable kernels (4.4 and 4.9) behavior
consistent with upstream.
thanks
-john
Re: Userland breakage from "Modify the device name as devfreq(X) for sysfs"
On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> On 2018년 05월 09일 08:17, John Stultz wrote:
>> Hey folks,
>> I wanted to bring up an issue we've recently tripped over, which was
>> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> devfreq(X) for sysfs").
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4585fbcb5331fc910b7e553ad3efd0dd7b320d14
>>
>> That patch replaced paths like:
>>/sys/class/devfreq/ddr_devfreq/min_freq
>> and
>> /sys/class/devfreq/e82c.mali/min_freq
>>
>> With
>> /sys/class/devfreq/devfreq(0)/min_freq
>> and
>> /sys/class/devfreq/devfreq(1)/min_freq
>>
>>
>> This broke userspace we have that needs to work on 4.4, 4.9 and 4.14 (and
>> on).
>
> Firstly, I'm sorry to make some problem on userland.
>
>>
>> I wanted to try to ask to understand more about the rational for this
>> patch, as it doesn't make much sense to me, particularly as now it is
>> less obvious as to which path is for which device - and more
>> worrisome it could change depending on initialization order.
>
> Some linux framework used the their own prefix under "/sys/class/"
> for device such as input/pwm/hwmon/regulator and so on.
> (But, some linux framework used the device name directly without any changes)
>
> I thought that devfreq better to use use the consistent name.
> If user wanted to access the specific device with device name,
> the user can access the path of '/sys/devices/platform/...'.
>
> [Example on Exynos5433-based TM2 board]
> root@localhost:~# ls -al /sys/class/devfreq
> total 0
> drwxr-xr-x 2 root root 0 Jul 26 04:49 .
> drwxr-xr-x 50 root root 0 Jan 1 1970 ..
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq0 ->
> ../../devices/platform/soc/soc:bus0/devfreq/devfreq0
> lrwxrwxrwx 1 root root 0 Jul 26 04:49 devfreq1 ->
> ../../devices/platform/soc/soc:bus1/devfreq/devfreq1
> (skip)
>
> - User can access the devfreq device with specific device name.
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# pwd
> /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# ls
> available_frequencies devicemin_freq subsystemuevent
> available_governorsgovernor polling_interval target_freq
> cur_freq max_freq power trans_stat
>
> root@localhost:/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0# cat
> min_freq
> 16000
>
Sorry to not get back to you sooner on this. Was on vacation then this
discussion got buried in my inbox.
I do agree that it the consistency with other subsystems is an
improvement, but it still doesn't help our situation that userspace
applications can't consistently work between kernel versions, as even
if we go with the /sys/devices/platform/soc/soc:bus0/devfreq/devfreq0
path rather then the /sys/class/devfreq/ path, in older kernels the
/sys/devices/platform/soc/soc:bus0/devfreq/devfreq0 doesn't exist.
> But, there is one of my mistake. The /sys/class/devfreq/devfreq(X)
> doesn't have the 'name' attribute. So, the user cannot find the required
> device. It is my mistake. I'll add the 'name' attribute as following:
> - /sys/class/devfreq/devfreqX/name
I agree that would be an improvement.
>> Unfortunately, this wasn't noticed very quickly, as the patch has been
>> upstream now for some time. But I wanted to better understand why
>> this change was made, and see if we might consider reverting it, or
>> alternatively consider provide multiple sysfs links (both dev_name and
>> devfreq(N)) so that we can preserve compatibility?
>
> Unfortunately, there are no frameworks which provide the both dev_name and
> [defined prefix](N) link under /sys/class/. I'm not sure this way.
>
> As you comment, devfreq(number) is not fixed as the initialization order.
> After adding the 'name' attribute, the user can find the specific device.
>
> How about using the 'name' attribute to find the device
> after adding new 'name' attribute when access device through /sys/class?
I agree we need a name attribute so folks can tell the difference
between devices.
I'm also not too much of a stickler that the old ABI broke, as long as
we have some solution that works across kernels. So I'd request that
you at least make older -stable kernels (4.4 and 4.9) behavior
consistent with upstream.
thanks
-john
Re: linux-next: manual merge of the irqchip tree with the arm-soc tree
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>
> On 29/05/18 08:41, Alexandre Torgue wrote:
>>
>> Hi Stephen
>>
>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>
>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>
>>> between commit:
>>>
>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to
>>> stm32mp157c")
>>>
>>> from the arm-soc tree and commit:
>>>
>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for
>>> stm32mp157c")
>>>
>>> from the irqchip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your
>>> tree
>>> is submitted for merging. You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any
>>> particularly
>>> complex conflicts.
>>>
>>
>> Thanks for the fix (I will reorder nodes in a future patch). My
>> opinion
>> is that all STM32 DT patches should come through my STM32 tree. It is
>> my
>> role to fix this kind of conflicts. I thought it was a common rule
>> (driver patches go to sub-system maintainer tree and DT to the Machine
>> maintainer). For incoming next-series which contain DT+driver patches
>> I
>> will indicate clearly that I take DT patch. I'm right ?
>
> Happy to oblige. Can you make sure you sync up with Ludovic and define
> what you want to do?
Sorry I don't understand your reply. I just say that for series
containing DT patches + drivers patches, to my point of view it is more
safe that driver patches are taken by sub-system maintainer (you in this
case) and that I take DT patches in my tree.
>>>
>>> And I'm happy to let you deal with these patches. I'm just asking you
>>> sync with Ludovic to split the series on whichever boundary you wish to
>>> enforce.
>>
>> ok
>>
>>>
> In the meantime, I'm dropping the series altogether.
>
Why? We could keep it as Stephen fixed the merge issue.
>>>
>>> Well, you seem to have a strong opinion about who deals with what. I'll
>>> let Ludovic repost what you and him decide should go via the irqchip
>>> tree.
>>
>>
>> It's not a "strong" opinion just my point of view and maybe not the good
>> one. I thought that's the way of working was like I explained. If you prefer
>> 2 series (one for driver patches and another one for DT patches) I will be
>> happy with that.
>>
>> Ludovic, what is your opinion ?
>
>
> Hi everybody
>
> For this serie, I think we could keep like that with
> Stephen fix. New stm32 irqchip will be integrated (thanks Marc)
> with no conflict with usb (thanks Stephen).
>
> For next series, we may split driver and DT to avoid misunderstanding.
The general rule that we try to use is to always merge DT through the
arm-soc tree, even if the driver gets merged through the subsystem
tree. There should be no harm in doing this for new drivers (i.e. a
new driver won't regress if the DT update is missing, it just won't
probe/configure). And that way we can keep the conflicts internal to
our tree (ideally to the SoC maintainer tree) and not cause overhead
for other maintainers and Stephen.
So yes, for the future please do not submit the DT updates with the
drivers, or at the very least be very clear when you post them that
you don't want the driver maintainer to apply them.
-Olof
Re: linux-next: manual merge of the irqchip tree with the arm-soc tree
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>
> On 29/05/18 08:41, Alexandre Torgue wrote:
>>
>> Hi Stephen
>>
>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>
>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>
>>> between commit:
>>>
>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to
>>> stm32mp157c")
>>>
>>> from the arm-soc tree and commit:
>>>
>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for
>>> stm32mp157c")
>>>
>>> from the irqchip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your
>>> tree
>>> is submitted for merging. You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any
>>> particularly
>>> complex conflicts.
>>>
>>
>> Thanks for the fix (I will reorder nodes in a future patch). My
>> opinion
>> is that all STM32 DT patches should come through my STM32 tree. It is
>> my
>> role to fix this kind of conflicts. I thought it was a common rule
>> (driver patches go to sub-system maintainer tree and DT to the Machine
>> maintainer). For incoming next-series which contain DT+driver patches
>> I
>> will indicate clearly that I take DT patch. I'm right ?
>
> Happy to oblige. Can you make sure you sync up with Ludovic and define
> what you want to do?
Sorry I don't understand your reply. I just say that for series
containing DT patches + drivers patches, to my point of view it is more
safe that driver patches are taken by sub-system maintainer (you in this
case) and that I take DT patches in my tree.
>>>
>>> And I'm happy to let you deal with these patches. I'm just asking you
>>> sync with Ludovic to split the series on whichever boundary you wish to
>>> enforce.
>>
>> ok
>>
>>>
> In the meantime, I'm dropping the series altogether.
>
Why? We could keep it as Stephen fixed the merge issue.
>>>
>>> Well, you seem to have a strong opinion about who deals with what. I'll
>>> let Ludovic repost what you and him decide should go via the irqchip
>>> tree.
>>
>>
>> It's not a "strong" opinion just my point of view and maybe not the good
>> one. I thought that's the way of working was like I explained. If you prefer
>> 2 series (one for driver patches and another one for DT patches) I will be
>> happy with that.
>>
>> Ludovic, what is your opinion ?
>
>
> Hi everybody
>
> For this serie, I think we could keep like that with
> Stephen fix. New stm32 irqchip will be integrated (thanks Marc)
> with no conflict with usb (thanks Stephen).
>
> For next series, we may split driver and DT to avoid misunderstanding.
The general rule that we try to use is to always merge DT through the
arm-soc tree, even if the driver gets merged through the subsystem
tree. There should be no harm in doing this for new drivers (i.e. a
new driver won't regress if the DT update is missing, it just won't
probe/configure). And that way we can keep the conflicts internal to
our tree (ideally to the SoC maintainer tree) and not cause overhead
for other maintainers and Stephen.
So yes, for the future please do not submit the DT updates with the
drivers, or at the very least be very clear when you post them that
you don't want the driver maintainer to apply them.
-Olof
linux-next: manual merge of the regulator tree with the arm-soc tree
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
from the regulator tree.
I fixed it up (see below - it may be better done) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276,759fa18f6ab4..
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -203,10 -203,8 +203,10 @@@ static struct resource latch2_resources
},
};
- #define LATCH2_LABEL "latch2"
++#define LATCH2_LABEL "ams-delta-latch2"
+
static struct bgpio_pdata latch2_pdata = {
- .label = "ams-delta-latch2",
+ .label = LATCH2_LABEL,
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@@ -303,6 -288,16 +302,15 @@@ static struct platform_device modem_nre
},
};
+ static struct gpiod_lookup_table modem_nreset_gpiod_table = {
+ .dev_id = "reg-fixed-voltage",
+ .table = {
- /* The AMS_DELTA_GPIO_PIN_MODEM_NRESET is at offset 12 */
- GPIO_LOOKUP("ams-delta-latch2", 12,
++ GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_MODEM_NRESET,
+ "enable", GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
struct modem_private_data {
struct regulator *regulator;
};
@@@ -658,15 -581,7 +666,15 @@@ static int __init late_init(void
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+ /*
+ * As soon as devices have been registered, assign their dev_names
+ * to respective GPIO lookup tables before they are added.
+ */
+ ams_delta_lcd_gpio_table.dev_id = dev_name(_delta_lcd_device.dev);
+ ams_delta_nand_gpio_table.dev_id = dev_name(_delta_nand_device.dev);
+
+ gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
-
+ gpiod_add_lookup_table(_nreset_gpiod_table);
err = platform_device_register(_nreset_device);
if (err) {
pr_err("Couldn't register the modem regulator device\n");
pgps02iybZDpN.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the regulator tree with the arm-soc tree
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
from the regulator tree.
I fixed it up (see below - it may be better done) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276,759fa18f6ab4..
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -203,10 -203,8 +203,10 @@@ static struct resource latch2_resources
},
};
- #define LATCH2_LABEL "latch2"
++#define LATCH2_LABEL "ams-delta-latch2"
+
static struct bgpio_pdata latch2_pdata = {
- .label = "ams-delta-latch2",
+ .label = LATCH2_LABEL,
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@@ -303,6 -288,16 +302,15 @@@ static struct platform_device modem_nre
},
};
+ static struct gpiod_lookup_table modem_nreset_gpiod_table = {
+ .dev_id = "reg-fixed-voltage",
+ .table = {
- /* The AMS_DELTA_GPIO_PIN_MODEM_NRESET is at offset 12 */
- GPIO_LOOKUP("ams-delta-latch2", 12,
++ GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_MODEM_NRESET,
+ "enable", GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
struct modem_private_data {
struct regulator *regulator;
};
@@@ -658,15 -581,7 +666,15 @@@ static int __init late_init(void
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+ /*
+ * As soon as devices have been registered, assign their dev_names
+ * to respective GPIO lookup tables before they are added.
+ */
+ ams_delta_lcd_gpio_table.dev_id = dev_name(_delta_lcd_device.dev);
+ ams_delta_nand_gpio_table.dev_id = dev_name(_delta_nand_device.dev);
+
+ gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
-
+ gpiod_add_lookup_table(_nreset_gpiod_table);
err = platform_device_register(_nreset_device);
if (err) {
pr_err("Couldn't register the modem regulator device\n");
pgps02iybZDpN.pgp
Description: OpenPGP digital signature
[PATCH] ANDROID: binder: rename parameter to resolve name collision.
From: Kuang Rufan
both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
rename the one in binder_alloc.c to 'alloc_debug_mask'.
Signed-off-by: Kuang Rufan
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 5a426c877dfb..3850dab493d4 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -42,7 +42,7 @@ enum {
};
static uint32_t binder_alloc_debug_mask;
-module_param_named(debug_mask, binder_alloc_debug_mask,
+module_param_named(alloc_debug_mask, binder_alloc_debug_mask,
uint, 0644);
#define binder_alloc_debug(mask, x...) \
--
2.15.1 (Apple Git-101)
[PATCH] ANDROID: binder: rename parameter to resolve name collision.
From: Kuang Rufan
both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
rename the one in binder_alloc.c to 'alloc_debug_mask'.
Signed-off-by: Kuang Rufan
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 5a426c877dfb..3850dab493d4 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -42,7 +42,7 @@ enum {
};
static uint32_t binder_alloc_debug_mask;
-module_param_named(debug_mask, binder_alloc_debug_mask,
+module_param_named(alloc_debug_mask, binder_alloc_debug_mask,
uint, 0644);
#define binder_alloc_debug(mask, x...) \
--
2.15.1 (Apple Git-101)
Re: [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote: > Can you explain why you think allocating a page here is a major problem? Because a larger allocation is more likely to fail. And if you fail the allocation, you also fail to free more pages, which _is_ a problem. So better avoid any allocations in code paths that are about freeing memory. > If we just revert, please apply patch 1/3 first. This patch address the > BUG_ON issue on PAE. This is a real issue that needs a fix ASAP. It does not address the problem of dirty page-walk caches on x86-64. > The page-directory cache issue on x64, which is addressed by patch 3/3, > is a theoretical issue that I could not hit by putting ioremap() calls > into a loop for a whole day. Nobody hit this issue, either. How do you know you didn't hit that issue? It might cause silent data corruption, which might not be easily detected. > The simple revert patch Joerg posted a while ago causes > pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings > to fall into pte mappings on my test systems. This can be seen as a > degradation, and I am afraid that it is more harmful than good. The plain revert just removes all the issues with the dirty TLB that the original patch introduced and prevents huge mappings from being established when there have been smaller mappings before. This is not ideal, but at least its is consistent and does not leak pages and leaves no dirty TLBs. So this is the easiest and most reliable fix for this stage in the release process. Regards, Joerg
Re: [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote: > Can you explain why you think allocating a page here is a major problem? Because a larger allocation is more likely to fail. And if you fail the allocation, you also fail to free more pages, which _is_ a problem. So better avoid any allocations in code paths that are about freeing memory. > If we just revert, please apply patch 1/3 first. This patch address the > BUG_ON issue on PAE. This is a real issue that needs a fix ASAP. It does not address the problem of dirty page-walk caches on x86-64. > The page-directory cache issue on x64, which is addressed by patch 3/3, > is a theoretical issue that I could not hit by putting ioremap() calls > into a loop for a whole day. Nobody hit this issue, either. How do you know you didn't hit that issue? It might cause silent data corruption, which might not be easily detected. > The simple revert patch Joerg posted a while ago causes > pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings > to fall into pte mappings on my test systems. This can be seen as a > degradation, and I am afraid that it is more harmful than good. The plain revert just removes all the issues with the dirty TLB that the original patch introduced and prevents huge mappings from being established when there have been smaller mappings before. This is not ideal, but at least its is consistent and does not leak pages and leaves no dirty TLBs. So this is the easiest and most reliable fix for this stage in the release process. Regards, Joerg
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote: > On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote: > > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > >> Adding pci=safemode kernel command line parameter to turn off all PCI > >> Express service driver as well as all optional PCIe features such as LTR, > >> Extended tags, Relaxed Ordering etc. > >> > >> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > >> reconfigured with by the kernel in case BIOS hands off a broken > >> configuration. > > > > Why not fix the BIOS? That's what sane platforms do :) > > > >> > >> Signed-off-by: Sinan Kaya > >> --- > >> Documentation/admin-guide/kernel-parameters.txt | 2 ++ > >> drivers/pci/pci.c | 7 +++ > >> drivers/pci/pci.h | 2 ++ > >> drivers/pci/pcie/portdrv_core.c | 2 +- > >> drivers/pci/probe.c | 6 ++ > >> 5 files changed, 18 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt > >> b/Documentation/admin-guide/kernel-parameters.txt > >> index 641ec9c..247adbb 100644 > >> --- a/Documentation/admin-guide/kernel-parameters.txt > >> +++ b/Documentation/admin-guide/kernel-parameters.txt > >> @@ -3153,6 +3153,8 @@ > >>noari do not use PCIe ARI. > >>noats [PCIE, Intel-IOMMU, AMD-IOMMU] > >>do not use PCIe ATS (and IOMMU device IOTLB). > >> + safemodeturns of all optinal PCI features. Useful > >> + for bringup/troubleshooting. > > > > s/optinal/optional/ ? > > sure. > > > > > And you should explain what exactly in PCI is "optional". Who defines > > this and where is that list and what can go wrong if those options are > > not enabled? > > Bjorn and I discussed the need for such a "safe" mode feature when you > want to bring up PCI for a platform. You want to turn off everything as > a starter and just stick to bare minimum. > > I can add a few words describing them. The goal of this option is to keep > base PCI features with MSI only. Things like PME, AER, ASPM, Extended > Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode > is certainly not intended for production environments. Ok, then you should say that here, or somewhere, so that people know this. Otherwise people will see that "hey this lets my hardware boot!" and then never change it :( > I can taint the kernel as a suggestion. I would not worry about that. > I defined minimum as just booting a device and to be able to do DMA traffic > only with 0 optimization Ok, again, just document this really well, so that people do not have questions and start wondering why their devices barely seem to work. thanks, greg k-h
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote: > On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote: > > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > >> Adding pci=safemode kernel command line parameter to turn off all PCI > >> Express service driver as well as all optional PCIe features such as LTR, > >> Extended tags, Relaxed Ordering etc. > >> > >> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > >> reconfigured with by the kernel in case BIOS hands off a broken > >> configuration. > > > > Why not fix the BIOS? That's what sane platforms do :) > > > >> > >> Signed-off-by: Sinan Kaya > >> --- > >> Documentation/admin-guide/kernel-parameters.txt | 2 ++ > >> drivers/pci/pci.c | 7 +++ > >> drivers/pci/pci.h | 2 ++ > >> drivers/pci/pcie/portdrv_core.c | 2 +- > >> drivers/pci/probe.c | 6 ++ > >> 5 files changed, 18 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/admin-guide/kernel-parameters.txt > >> b/Documentation/admin-guide/kernel-parameters.txt > >> index 641ec9c..247adbb 100644 > >> --- a/Documentation/admin-guide/kernel-parameters.txt > >> +++ b/Documentation/admin-guide/kernel-parameters.txt > >> @@ -3153,6 +3153,8 @@ > >>noari do not use PCIe ARI. > >>noats [PCIE, Intel-IOMMU, AMD-IOMMU] > >>do not use PCIe ATS (and IOMMU device IOTLB). > >> + safemodeturns of all optinal PCI features. Useful > >> + for bringup/troubleshooting. > > > > s/optinal/optional/ ? > > sure. > > > > > And you should explain what exactly in PCI is "optional". Who defines > > this and where is that list and what can go wrong if those options are > > not enabled? > > Bjorn and I discussed the need for such a "safe" mode feature when you > want to bring up PCI for a platform. You want to turn off everything as > a starter and just stick to bare minimum. > > I can add a few words describing them. The goal of this option is to keep > base PCI features with MSI only. Things like PME, AER, ASPM, Extended > Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode > is certainly not intended for production environments. Ok, then you should say that here, or somewhere, so that people know this. Otherwise people will see that "hey this lets my hardware boot!" and then never change it :( > I can taint the kernel as a suggestion. I would not worry about that. > I defined minimum as just booting a device and to be able to do DMA traffic > only with 0 optimization Ok, again, just document this really well, so that people do not have questions and start wondering why their devices barely seem to work. thanks, greg k-h
RE: [kbuild-all] include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, l
>
> Hi Al,
>
> FYI, the error/warning still remains.
hi AI, kindly ignore this, the warning below may be caused by gcc-8.1 upgrade.
we will double check to reduce noises.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0044cdeb731313f20b63cb5644de7588731de32b
> commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
> sparc_remap_file_pages() to SYSCALL_DEFINE
> date: 2 months ago
> config: sparc-defconfig (attached as .config)
> compiler: sparc-linux-gcc (GCC) 8.1.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout a0d32ad366bb4235267380b341fcae8307f51044
> # save the attached .config to linux build tree
> make.cross ARCH=sparc
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between
> functions of
> incompatible types 'long int(long unsigned int, long unsigned int, long
> unsigned
> int, long unsigned int, long unsigned int, long unsigned int)' and 'long
> int(long int,
> long int, long int, long int, long int, long int)'
> [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
> functions of incompatible types 'long int(char *, int)' and 'long int(long
> int, long
> int)' [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
> functions
> of incompatible types 'long int(int, const struct sigaction *, struct
> sigaction *, void
> *, size_t)' {aka 'long int(int, const struct sigaction *, struct sigaction
> *, void *,
> unsigned int)'} and 'long int(long int, long int, long int, long int,
> long int)' [-
> Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:200:36:
RE: [kbuild-all] include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, l
>
> Hi Al,
>
> FYI, the error/warning still remains.
hi AI, kindly ignore this, the warning below may be caused by gcc-8.1 upgrade.
we will double check to reduce noises.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0044cdeb731313f20b63cb5644de7588731de32b
> commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
> sparc_remap_file_pages() to SYSCALL_DEFINE
> date: 2 months ago
> config: sparc-defconfig (attached as .config)
> compiler: sparc-linux-gcc (GCC) 8.1.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout a0d32ad366bb4235267380b341fcae8307f51044
> # save the attached .config to linux build tree
> make.cross ARCH=sparc
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between
> functions of
> incompatible types 'long int(long unsigned int, long unsigned int, long
> unsigned
> int, long unsigned int, long unsigned int, long unsigned int)' and 'long
> int(long int,
> long int, long int, long int, long int, long int)'
> [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:201:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
> 'SYSCALL_DEFINE6'
> SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
> functions of incompatible types 'long int(char *, int)' and 'long int(long
> int, long
> int)' [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:215:18: note: aliased declaration here
> asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:197:36: note: in expansion of macro
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name,
> __VA_ARGS__)
>^~~
>arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
> 'SYSCALL_DEFINE2'
> SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
> ^~~
>include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
> functions
> of incompatible types 'long int(int, const struct sigaction *, struct
> sigaction *, void
> *, size_t)' {aka 'long int(int, const struct sigaction *, struct sigaction
> *, void *,
> unsigned int)'} and 'long int(long int, long int, long int, long int,
> long int)' [-
> Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
>include/linux/syscalls.h:207:2: note: in expansion of macro
> '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^
>include/linux/syscalls.h:200:36:
Re: [PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Hi Arnaldo,
On Wed, May 30, 2018 at 12:49:27PM +0800, Leo Yan wrote:
> Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
> from tool to browser") has added extra parameter for functions, but it
> missed to update hist_entry__tui_annotate() declaration for
> !HAVE_SLANG_SUPPORT configuration so this results in regression for perf
> tool building failure.
>
> This patch is to update hist_entry__tui_annotate() declaration for
> new added argument '*annotation_opts'.
Seems to me this fixing should be merged into the patch "perf hists
browser: Pass annotation_options from tool to browser" because I
encountered this issue on perf/core branch. Just remind for this.
Thanks,
Leo Yan
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/hist.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index 5f30758..cafafbf 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
> map_symbol *ms __maybe_unused,
>
> static inline int hist_entry__tui_annotate(struct hist_entry *he
> __maybe_unused,
> struct perf_evsel *evsel
> __maybe_unused,
> -struct hist_browser_timer *hbt
> __maybe_unused)
> +struct hist_browser_timer *hbt
> __maybe_unused,
> +struct annotation_options
> *annotation_opts __maybe_unused)
> {
> return 0;
> }
> --
> 2.7.4
>
Re: [PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Hi Arnaldo,
On Wed, May 30, 2018 at 12:49:27PM +0800, Leo Yan wrote:
> Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
> from tool to browser") has added extra parameter for functions, but it
> missed to update hist_entry__tui_annotate() declaration for
> !HAVE_SLANG_SUPPORT configuration so this results in regression for perf
> tool building failure.
>
> This patch is to update hist_entry__tui_annotate() declaration for
> new added argument '*annotation_opts'.
Seems to me this fixing should be merged into the patch "perf hists
browser: Pass annotation_options from tool to browser" because I
encountered this issue on perf/core branch. Just remind for this.
Thanks,
Leo Yan
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/hist.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index 5f30758..cafafbf 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
> map_symbol *ms __maybe_unused,
>
> static inline int hist_entry__tui_annotate(struct hist_entry *he
> __maybe_unused,
> struct perf_evsel *evsel
> __maybe_unused,
> -struct hist_browser_timer *hbt
> __maybe_unused)
> +struct hist_browser_timer *hbt
> __maybe_unused,
> +struct annotation_options
> *annotation_opts __maybe_unused)
> {
> return 0;
> }
> --
> 2.7.4
>
Re: [PATCH 2/2] cpufreq: Use static SRCU initializer
On 25-05-18, 12:19, Sebastian Andrzej Siewior wrote:
> Use the static SRCU initializer for `cpufreq_transition_notifier_list'.
> This avoids the init_cpufreq_transition_notifier_list() initcall. Its
> only purpose is to initialize the SRCU notifier once during boot and set
> another variable which is used as an indicator whether the init was
> perfromed before cpufreq_register_notifier() was used.
>
> Cc: "Rafael J. Wysocki"
> CC: Viresh Kumar
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/cpufreq/cpufreq.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 075d18f6ba7a..3f7b502cfb1e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -89,16 +89,7 @@ static void cpufreq_governor_limits(struct cpufreq_policy
> *policy);
> * The mutex locks both lists.
> */
> static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
> -static struct srcu_notifier_head cpufreq_transition_notifier_list;
> -
> -static bool init_cpufreq_transition_notifier_list_called;
> -static int __init init_cpufreq_transition_notifier_list(void)
> -{
> - srcu_init_notifier_head(_transition_notifier_list);
> - init_cpufreq_transition_notifier_list_called = true;
> - return 0;
> -}
> -pure_initcall(init_cpufreq_transition_notifier_list);
> +SRCU_NOTIFIER_HEAD_STATIC(cpufreq_transition_notifier_list);
>
> static int off __read_mostly;
> static int cpufreq_disabled(void)
> @@ -1764,8 +1755,6 @@ int cpufreq_register_notifier(struct notifier_block
> *nb, unsigned int list)
> if (cpufreq_disabled())
> return -EINVAL;
>
> - WARN_ON(!init_cpufreq_transition_notifier_list_called);
> -
> switch (list) {
> case CPUFREQ_TRANSITION_NOTIFIER:
> mutex_lock(_fast_switch_lock);
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 2/2] cpufreq: Use static SRCU initializer
On 25-05-18, 12:19, Sebastian Andrzej Siewior wrote:
> Use the static SRCU initializer for `cpufreq_transition_notifier_list'.
> This avoids the init_cpufreq_transition_notifier_list() initcall. Its
> only purpose is to initialize the SRCU notifier once during boot and set
> another variable which is used as an indicator whether the init was
> perfromed before cpufreq_register_notifier() was used.
>
> Cc: "Rafael J. Wysocki"
> CC: Viresh Kumar
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/cpufreq/cpufreq.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 075d18f6ba7a..3f7b502cfb1e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -89,16 +89,7 @@ static void cpufreq_governor_limits(struct cpufreq_policy
> *policy);
> * The mutex locks both lists.
> */
> static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
> -static struct srcu_notifier_head cpufreq_transition_notifier_list;
> -
> -static bool init_cpufreq_transition_notifier_list_called;
> -static int __init init_cpufreq_transition_notifier_list(void)
> -{
> - srcu_init_notifier_head(_transition_notifier_list);
> - init_cpufreq_transition_notifier_list_called = true;
> - return 0;
> -}
> -pure_initcall(init_cpufreq_transition_notifier_list);
> +SRCU_NOTIFIER_HEAD_STATIC(cpufreq_transition_notifier_list);
>
> static int off __read_mostly;
> static int cpufreq_disabled(void)
> @@ -1764,8 +1755,6 @@ int cpufreq_register_notifier(struct notifier_block
> *nb, unsigned int list)
> if (cpufreq_disabled())
> return -EINVAL;
>
> - WARN_ON(!init_cpufreq_transition_notifier_list_called);
> -
> switch (list) {
> case CPUFREQ_TRANSITION_NOTIFIER:
> mutex_lock(_fast_switch_lock);
Acked-by: Viresh Kumar
--
viresh
include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned i
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
sparc_remap_file_pages() to SYSCALL_DEFINE
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a0d32ad366bb4235267380b341fcae8307f51044
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
of incompatible types 'long int(long unsigned int, long unsigned int, long
unsigned int, long unsigned int, long unsigned int, long unsigned int)' and
'long int(long int, long int, long int, long int, long int, long int)'
[-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
functions of incompatible types 'long int(char *, int)' and 'long int(long int,
long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction, int, sig,
include/linux/syscalls.h:211:18: error: 'sys_sparc_remap_file_pages' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned i
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
sparc_remap_file_pages() to SYSCALL_DEFINE
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a0d32ad366bb4235267380b341fcae8307f51044
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
of incompatible types 'long int(long unsigned int, long unsigned int, long
unsigned int, long unsigned int, long unsigned int, long unsigned int)' and
'long int(long int, long int, long int, long int, long int, long int)'
[-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
functions of incompatible types 'long int(char *, int)' and 'long int(long int,
long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction, int, sig,
[PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
from tool to browser") has added extra parameter for functions, but it
missed to update hist_entry__tui_annotate() declaration for
!HAVE_SLANG_SUPPORT configuration so this results in regression for perf
tool building failure.
This patch is to update hist_entry__tui_annotate() declaration for
new added argument '*annotation_opts'.
Signed-off-by: Leo Yan
---
tools/perf/util/hist.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 5f30758..cafafbf 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
map_symbol *ms __maybe_unused,
static inline int hist_entry__tui_annotate(struct hist_entry *he
__maybe_unused,
struct perf_evsel *evsel
__maybe_unused,
- struct hist_browser_timer *hbt
__maybe_unused)
+ struct hist_browser_timer *hbt
__maybe_unused,
+ struct annotation_options
*annotation_opts __maybe_unused)
{
return 0;
}
--
2.7.4
[PATCH] perf hists browser: Fix stale hist_entry__tui_annotate() declaration
Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
from tool to browser") has added extra parameter for functions, but it
missed to update hist_entry__tui_annotate() declaration for
!HAVE_SLANG_SUPPORT configuration so this results in regression for perf
tool building failure.
This patch is to update hist_entry__tui_annotate() declaration for
new added argument '*annotation_opts'.
Signed-off-by: Leo Yan
---
tools/perf/util/hist.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 5f30758..cafafbf 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -460,7 +460,8 @@ static inline int map_symbol__tui_annotate(struct
map_symbol *ms __maybe_unused,
static inline int hist_entry__tui_annotate(struct hist_entry *he
__maybe_unused,
struct perf_evsel *evsel
__maybe_unused,
- struct hist_browser_timer *hbt
__maybe_unused)
+ struct hist_browser_timer *hbt
__maybe_unused,
+ struct annotation_options
*annotation_opts __maybe_unused)
{
return 0;
}
--
2.7.4
[PATCH] arm64: mm: mark tramp_pg_dir read-only
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process can
then modify kernel text directly through this mapping. In this
way, an arbitrary write can be converted to multiple arbitrary
writes.
Signed-off-by: YaoJun
---
arch/arm64/mm/mmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..ac4b22c7e435 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ update_mapping_prot(__pa_symbol(tramp_pg_dir),
+ (unsigned long)tramp_pg_dir,
+ PGD_SIZE, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
[PATCH] arm64: mm: mark tramp_pg_dir read-only
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process can
then modify kernel text directly through this mapping. In this
way, an arbitrary write can be converted to multiple arbitrary
writes.
Signed-off-by: YaoJun
---
arch/arm64/mm/mmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..ac4b22c7e435 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ update_mapping_prot(__pa_symbol(tramp_pg_dir),
+ (unsigned long)tramp_pg_dir,
+ PGD_SIZE, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
Re: [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
On 29-05-18, 15:18, Krzysztof Kozlowski wrote: > Thanks for the patch. > > In case of Exynos, the booting CPU always has these information in DT > and the booting CPU cannot be changed (chosen by firmware/hardware > configuration). But can the booting CPU be offlined ? If yes, then this is how things are broken right now. Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert cpufreq driver and that will try to find these properties in CPU1. > Therefore there is no real risk of falling although > for correctness of DT your change makes sense. > > It is too late for this cycle for me so I'll pick it up after merge window. > Alternatively, arm-soc guys can pick it up directly with my tag: > Reviewed-by: Krzysztof Kozlowski No worries, you can pick it up later on. -- viresh
Re: [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
On 29-05-18, 15:18, Krzysztof Kozlowski wrote: > Thanks for the patch. > > In case of Exynos, the booting CPU always has these information in DT > and the booting CPU cannot be changed (chosen by firmware/hardware > configuration). But can the booting CPU be offlined ? If yes, then this is how things are broken right now. Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert cpufreq driver and that will try to find these properties in CPU1. > Therefore there is no real risk of falling although > for correctness of DT your change makes sense. > > It is too late for this cycle for me so I'll pick it up after merge window. > Alternatively, arm-soc guys can pick it up directly with my tag: > Reviewed-by: Krzysztof Kozlowski No worries, you can pick it up later on. -- viresh
Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote: > Dave Chinner writes: > > > Yeah, the are some fairly big process and policy things that > > need to be decided here. Not just at the kernel level, but at > > distro and app infrastructure level too. > > > > I was originally sceptical of supporting kernel filesystems via > > lkl, but the desire for unprivileged mounts has not gone away > > and so I'm less worried about accessing filesystems that way > > than I am of letting the kernel parse untrusted images from > > untrusted users... > > There is also the more readily available libguestfs which doesn't > support as many filesystems but does seem available in most linux > distributions already. It already has a fuse option available > with guestmount. I may have to dig in there and see how to make > it available without using fusermount. That only provides host access to filesystems mounted inside guest VMs, right? AFAIA, libguestfs is not providing a FUSE implementation that mounts and parses raw XFS images. e.g it barely understands anything XFS, and that which it does is via running and screen-scraping the output of XFS's userspace management tools... > > I'm not sure what the correct forum for this is - wasn't this > > something the Plumbers conference was supposed to facilitate? > > Yes. If we all need to be in a room and talk about things. > It is early enough in the planning for Plumers that we could > definitely schedule a talk or a BOF for this. Ok. I have no idea if I'll be at plumbers - it's an awful long way from where I am Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote: > Dave Chinner writes: > > > Yeah, the are some fairly big process and policy things that > > need to be decided here. Not just at the kernel level, but at > > distro and app infrastructure level too. > > > > I was originally sceptical of supporting kernel filesystems via > > lkl, but the desire for unprivileged mounts has not gone away > > and so I'm less worried about accessing filesystems that way > > than I am of letting the kernel parse untrusted images from > > untrusted users... > > There is also the more readily available libguestfs which doesn't > support as many filesystems but does seem available in most linux > distributions already. It already has a fuse option available > with guestmount. I may have to dig in there and see how to make > it available without using fusermount. That only provides host access to filesystems mounted inside guest VMs, right? AFAIA, libguestfs is not providing a FUSE implementation that mounts and parses raw XFS images. e.g it barely understands anything XFS, and that which it does is via running and screen-scraping the output of XFS's userspace management tools... > > I'm not sure what the correct forum for this is - wasn't this > > something the Plumbers conference was supposed to facilitate? > > Yes. If we all need to be in a room and talk about things. > It is early enough in the planning for Plumers that we could > definitely schedule a talk or a BOF for this. Ok. I have no idea if I'll be at plumbers - it's an awful long way from where I am Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH] PCI: move early dump functionality from x86 arch into the common code
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c| 50 -
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios[X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h
b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8
offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8
offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci :%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256,
false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0x)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
-
[PATCH] PCI: move early dump functionality from x86 arch into the common code
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c| 50 -
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios[X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h
b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8
offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8
offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci :%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256,
false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0x)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
-
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a dedicated module for the shared code and export corresponding
> symbols for other kernel modules.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Makefile | 1 +
> drivers/xen/balloon.c | 71 ++
> drivers/xen/mem-reservation.c | 134 ++
> include/xen/mem_reservation.h | 29
> 4 files changed, 170 insertions(+), 65 deletions(-)
> create mode 100644 drivers/xen/mem-reservation.c
> create mode 100644 include/xen/mem_reservation.h
Can you please name this include/xen/mem-reservation.h ?
>
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 451e833f5931..3c87b0c3aca6 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> obj-$(CONFIG_X86)+= fallback.o
> obj-y+= grant-table.o features.o balloon.o manage.o preempt.o time.o
> +obj-y+= mem-reservation.o
> obj-y+= events/
> obj-y+= xenbus/
>
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 065f0b607373..57b482d67a3a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
>
> static int xen_hotplug_unpopulated;
>
> @@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
> balloon_process);
> #define GFP_BALLOON \
> (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
>
> -static void scrub_page(struct page *page)
> -{
> -#ifdef CONFIG_XEN_SCRUB_PAGES
> - clear_highpage(page);
> -#endif
> -}
> -
> /* balloon_append: add the given page to the balloon. */
> static void __balloon_append(struct page *page)
> {
> @@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> int rc;
> unsigned long i;
> struct page *page;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> nr_pages = ARRAY_SIZE(frame_list);
> @@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_next_page(page);
> }
>
> - set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
> + rc = xenmem_reservation_increase(nr_pages, frame_list);
> if (rc <= 0)
> return BP_EAGAIN;
>
> @@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_retrieve(false);
> BUG_ON(page == NULL);
>
> -#ifdef CONFIG_XEN_HAVE_PVMMU
> - /*
> - * We don't support PV MMU when Linux and Xen is using
> - * different page granularity.
> - */
> - BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
> -
> - if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> - unsigned long pfn = page_to_pfn(page);
> -
> - set_phys_to_machine(pfn, frame_list[i]);
> -
> - /* Link back into the page tables if not highmem. */
> - if (!PageHighMem(page)) {
> - int ret;
> - ret = HYPERVISOR_update_va_mapping(
> - (unsigned long)__va(pfn <<
> PAGE_SHIFT),
> - mfn_pte(frame_list[i],
> PAGE_KERNEL),
> - 0);
> - BUG_ON(ret);
> - }
> - }
> -#endif
> + xenmem_reservation_va_mapping_update(1, , _list[i]);
>
> /* Relinquish the page back to the allocator. */
> free_reserved_page(page);
> @@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> unsigned long i;
> struct page *page, *tmp;
> int ret;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
> LIST_HEAD(pages);
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> @@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> break;
> }
> adjust_managed_page_count(page,
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a dedicated module for the shared code and export corresponding
> symbols for other kernel modules.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Makefile | 1 +
> drivers/xen/balloon.c | 71 ++
> drivers/xen/mem-reservation.c | 134 ++
> include/xen/mem_reservation.h | 29
> 4 files changed, 170 insertions(+), 65 deletions(-)
> create mode 100644 drivers/xen/mem-reservation.c
> create mode 100644 include/xen/mem_reservation.h
Can you please name this include/xen/mem-reservation.h ?
>
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 451e833f5931..3c87b0c3aca6 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> obj-$(CONFIG_X86)+= fallback.o
> obj-y+= grant-table.o features.o balloon.o manage.o preempt.o time.o
> +obj-y+= mem-reservation.o
> obj-y+= events/
> obj-y+= xenbus/
>
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 065f0b607373..57b482d67a3a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
>
> static int xen_hotplug_unpopulated;
>
> @@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
> balloon_process);
> #define GFP_BALLOON \
> (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
>
> -static void scrub_page(struct page *page)
> -{
> -#ifdef CONFIG_XEN_SCRUB_PAGES
> - clear_highpage(page);
> -#endif
> -}
> -
> /* balloon_append: add the given page to the balloon. */
> static void __balloon_append(struct page *page)
> {
> @@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> int rc;
> unsigned long i;
> struct page *page;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> nr_pages = ARRAY_SIZE(frame_list);
> @@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_next_page(page);
> }
>
> - set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
> + rc = xenmem_reservation_increase(nr_pages, frame_list);
> if (rc <= 0)
> return BP_EAGAIN;
>
> @@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_retrieve(false);
> BUG_ON(page == NULL);
>
> -#ifdef CONFIG_XEN_HAVE_PVMMU
> - /*
> - * We don't support PV MMU when Linux and Xen is using
> - * different page granularity.
> - */
> - BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
> -
> - if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> - unsigned long pfn = page_to_pfn(page);
> -
> - set_phys_to_machine(pfn, frame_list[i]);
> -
> - /* Link back into the page tables if not highmem. */
> - if (!PageHighMem(page)) {
> - int ret;
> - ret = HYPERVISOR_update_va_mapping(
> - (unsigned long)__va(pfn <<
> PAGE_SHIFT),
> - mfn_pte(frame_list[i],
> PAGE_KERNEL),
> - 0);
> - BUG_ON(ret);
> - }
> - }
> -#endif
> + xenmem_reservation_va_mapping_update(1, , _list[i]);
>
> /* Relinquish the page back to the allocator. */
> free_reserved_page(page);
> @@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> unsigned long i;
> struct page *page, *tmp;
> int ret;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
> LIST_HEAD(pages);
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> @@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> break;
> }
> adjust_managed_page_count(page,
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > Adding pci=safemode kernel command line parameter to turn off all PCI > Express service driver as well as all optional PCIe features such as LTR, > Extended tags, Relaxed Ordering etc. > > Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > reconfigured with by the kernel in case BIOS hands off a broken > configuration. Why not fix the BIOS? That's what sane platforms do :) > > Signed-off-by: Sinan Kaya > --- > Documentation/admin-guide/kernel-parameters.txt | 2 ++ > drivers/pci/pci.c | 7 +++ > drivers/pci/pci.h | 2 ++ > drivers/pci/pcie/portdrv_core.c | 2 +- > drivers/pci/probe.c | 6 ++ > 5 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 641ec9c..247adbb 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3153,6 +3153,8 @@ > noari do not use PCIe ARI. > noats [PCIE, Intel-IOMMU, AMD-IOMMU] > do not use PCIe ATS (and IOMMU device IOTLB). > + safemodeturns of all optinal PCI features. Useful > + for bringup/troubleshooting. s/optinal/optional/ ? And you should explain what exactly in PCI is "optional". Who defines this and where is that list and what can go wrong if those options are not enabled? In looking at your patch, I can't determine that at all, so there's no way that someone just looking at this sentence will be able to understand. thanks, greg k-h
Re: [PATCH] PCI: Add pci=safemode option
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote: > Adding pci=safemode kernel command line parameter to turn off all PCI > Express service driver as well as all optional PCIe features such as LTR, > Extended tags, Relaxed Ordering etc. > > Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be > reconfigured with by the kernel in case BIOS hands off a broken > configuration. Why not fix the BIOS? That's what sane platforms do :) > > Signed-off-by: Sinan Kaya > --- > Documentation/admin-guide/kernel-parameters.txt | 2 ++ > drivers/pci/pci.c | 7 +++ > drivers/pci/pci.h | 2 ++ > drivers/pci/pcie/portdrv_core.c | 2 +- > drivers/pci/probe.c | 6 ++ > 5 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 641ec9c..247adbb 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3153,6 +3153,8 @@ > noari do not use PCIe ARI. > noats [PCIE, Intel-IOMMU, AMD-IOMMU] > do not use PCIe ATS (and IOMMU device IOTLB). > + safemodeturns of all optinal PCI features. Useful > + for bringup/troubleshooting. s/optinal/optional/ ? And you should explain what exactly in PCI is "optional". Who defines this and where is that list and what can go wrong if those options are not enabled? In looking at your patch, I can't determine that at all, so there's no way that someone just looking at this sentence will be able to understand. thanks, greg k-h
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigne
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee076e81fc14ca79334d02970cea66604f183a14
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>> include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
>> of incompatible types 'long int(long unsigned int, long unsigned int, long
>> unsigned int, long unsigned int, long unsigned int, long unsigned int)'
>> and 'long int(long int, long int, long int, long int, long int, long
>> int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
>> include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
>> functions of incompatible types 'long int(char *, int)' and 'long int(long
>> int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction,
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigne
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee076e81fc14ca79334d02970cea66604f183a14
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>> include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
>> of incompatible types 'long int(long unsigned int, long unsigned int, long
>> unsigned int, long unsigned int, long unsigned int, long unsigned int)'
>> and 'long int(long int, long int, long int, long int, long int, long
>> int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
>> include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
>> functions of incompatible types 'long int(char *, int)' and 'long int(long
>> int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction,
Re: [PATCH v6 4/4] vsprintf: Add command line option debug_boot_weak_hash
On Mon, May 28, 2018 at 10:40:43AM -0700, Randy Dunlap wrote: > On 05/27/2018 06:46 PM, Tobin C. Harding wrote: > > Currently printing [hashed] pointers requires enough entropy to be > > available. Early in the boot sequence this may not be the case > > resulting in a dummy string '(ptrval)' being printed. This > > makes debugging the early boot sequence difficult. We can relax the > > requirement to use cryptographically secure hashing during debugging. > > This enables debugging while keeping development/production kernel > > behaviour the same. > > > > If new command line option debug_boot_weak_hash is enabled use > > cryptographically insecure hashing and hash pointer value immediately. > > > > Cc: Anna-Maria Gleixner > > Cc: Steven Rostedt > > Cc: Randy Dunlap > > Signed-off-by: Tobin C. Harding > > --- > > Documentation/admin-guide/kernel-parameters.txt | 9 + > > lib/vsprintf.c | 20 > > 2 files changed, 29 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index f2040d46f095..8a86d895343e 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -753,6 +753,15 @@ > > > > debug [KNL] Enable kernel debugging (events log level). > > > > Hi, > This is much more readable than the previous version. Thanks. Thanks for following up with this one Randy. Tobin
Re: [PATCH v6 4/4] vsprintf: Add command line option debug_boot_weak_hash
On Mon, May 28, 2018 at 10:40:43AM -0700, Randy Dunlap wrote: > On 05/27/2018 06:46 PM, Tobin C. Harding wrote: > > Currently printing [hashed] pointers requires enough entropy to be > > available. Early in the boot sequence this may not be the case > > resulting in a dummy string '(ptrval)' being printed. This > > makes debugging the early boot sequence difficult. We can relax the > > requirement to use cryptographically secure hashing during debugging. > > This enables debugging while keeping development/production kernel > > behaviour the same. > > > > If new command line option debug_boot_weak_hash is enabled use > > cryptographically insecure hashing and hash pointer value immediately. > > > > Cc: Anna-Maria Gleixner > > Cc: Steven Rostedt > > Cc: Randy Dunlap > > Signed-off-by: Tobin C. Harding > > --- > > Documentation/admin-guide/kernel-parameters.txt | 9 + > > lib/vsprintf.c | 20 > > 2 files changed, 29 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index f2040d46f095..8a86d895343e 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -753,6 +753,15 @@ > > > > debug [KNL] Enable kernel debugging (events log level). > > > > Hi, > This is much more readable than the previous version. Thanks. Thanks for following up with this one Randy. Tobin
Re: [PATCH 4.16 000/272] 4.16.13-stable review
On Tue, May 29, 2018 at 01:52:12PM -0600, Shuah Khan wrote: > On 05/28/2018 04:00 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.13 release. > > There are 272 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 should be made by Wed May 30 10:01:02 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.16.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.16 000/272] 4.16.13-stable review
On Tue, May 29, 2018 at 01:52:12PM -0600, Shuah Khan wrote: > On 05/28/2018 04:00 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.13 release. > > There are 272 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 should be made by Wed May 30 10:01:02 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.16.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 54 +--
> include/xen/grant_table.h | 3 +++
> 2 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 27be107d6480..d7488226e1f2 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
>
> -/**
> - * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> - * @nr_pages: number of pages to alloc
> - * @pages: returns the pages
> - */
> -int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +int gnttab_pages_set_private(int nr_pages, struct page **pages)
> {
> int i;
> - int ret;
> -
> - ret = alloc_xenballooned_pages(nr_pages, pages);
> - if (ret < 0)
> - return ret;
>
> for (i = 0; i < nr_pages; i++) {
> #if BITS_PER_LONG < 64
> struct xen_page_foreign *foreign;
>
> foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
> - if (!foreign) {
> - gnttab_free_pages(nr_pages, pages);
> + if (!foreign)
> return -ENOMEM;
> - }
> +
> set_page_private(pages[i], (unsigned long)foreign);
> #endif
> SetPagePrivate(pages[i]);
> @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page
> **pages)
>
> return 0;
> }
> -EXPORT_SYMBOL(gnttab_alloc_pages);
> +EXPORT_SYMBOL(gnttab_pages_set_private);
EXPORT_SYMBOL_GPL()
>
> /**
> - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> - * @nr_pages; number of pages to free
> - * @pages: the pages
> + * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> + * @nr_pages: number of pages to alloc
> + * @pages: returns the pages
> */
> -void gnttab_free_pages(int nr_pages, struct page **pages)
> +int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +{
> + int ret;
> +
> + ret = alloc_xenballooned_pages(nr_pages, pages);
> + if (ret < 0)
> + return ret;
> +
> + ret = gnttab_pages_set_private(nr_pages, pages);
> + if (ret < 0)
> + gnttab_free_pages(nr_pages, pages);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(gnttab_alloc_pages);
> +
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages)
> {
> int i;
>
> @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
> ClearPagePrivate(pages[i]);
> }
> }
> +}
> +EXPORT_SYMBOL(gnttab_pages_clear_private);
EXPORT_SYMBOL_GPL()
Juergen
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 54 +--
> include/xen/grant_table.h | 3 +++
> 2 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 27be107d6480..d7488226e1f2 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
>
> -/**
> - * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> - * @nr_pages: number of pages to alloc
> - * @pages: returns the pages
> - */
> -int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +int gnttab_pages_set_private(int nr_pages, struct page **pages)
> {
> int i;
> - int ret;
> -
> - ret = alloc_xenballooned_pages(nr_pages, pages);
> - if (ret < 0)
> - return ret;
>
> for (i = 0; i < nr_pages; i++) {
> #if BITS_PER_LONG < 64
> struct xen_page_foreign *foreign;
>
> foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
> - if (!foreign) {
> - gnttab_free_pages(nr_pages, pages);
> + if (!foreign)
> return -ENOMEM;
> - }
> +
> set_page_private(pages[i], (unsigned long)foreign);
> #endif
> SetPagePrivate(pages[i]);
> @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page
> **pages)
>
> return 0;
> }
> -EXPORT_SYMBOL(gnttab_alloc_pages);
> +EXPORT_SYMBOL(gnttab_pages_set_private);
EXPORT_SYMBOL_GPL()
>
> /**
> - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> - * @nr_pages; number of pages to free
> - * @pages: the pages
> + * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> + * @nr_pages: number of pages to alloc
> + * @pages: returns the pages
> */
> -void gnttab_free_pages(int nr_pages, struct page **pages)
> +int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +{
> + int ret;
> +
> + ret = alloc_xenballooned_pages(nr_pages, pages);
> + if (ret < 0)
> + return ret;
> +
> + ret = gnttab_pages_set_private(nr_pages, pages);
> + if (ret < 0)
> + gnttab_free_pages(nr_pages, pages);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(gnttab_alloc_pages);
> +
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages)
> {
> int i;
>
> @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
> ClearPagePrivate(pages[i]);
> }
> }
> +}
> +EXPORT_SYMBOL(gnttab_pages_clear_private);
EXPORT_SYMBOL_GPL()
Juergen
Re: [PATCH 3/3] f2fs: clean up symbol namespace
Hi Chao,
Thank you for the work.
I resolved some conflicts and modified some function names.
Please take a look at this.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/dir.c| 6 +++---
fs/f2fs/f2fs.h | 10 +-
fs/f2fs/file.c | 2 +-
fs/f2fs/gc.c | 4 ++--
fs/f2fs/namei.c | 4 ++--
fs/f2fs/recovery.c | 2 +-
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 078c2d5c5b2e..8eb184c3de84 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -24,7 +24,7 @@
#include
static struct kmem_cache *ino_entry_slab;
-struct kmem_cache *inode_entry_slab;
+struct kmem_cache *f2fs_inode_entry_slab;
void f2fs_stop_checkpoint(struct f2fs_sb_info *sbi, bool end_io)
{
@@ -1490,9 +1490,9 @@ int __init f2fs_create_checkpoint_caches(void)
sizeof(struct ino_entry));
if (!ino_entry_slab)
return -ENOMEM;
- inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
+ f2fs_inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
sizeof(struct inode_entry));
- if (!inode_entry_slab) {
+ if (!f2fs_inode_entry_slab) {
kmem_cache_destroy(ino_entry_slab);
return -ENOMEM;
}
@@ -1502,5 +1502,5 @@ int __init f2fs_create_checkpoint_caches(void)
void f2fs_destroy_checkpoint_caches(void)
{
kmem_cache_destroy(ino_entry_slab);
- kmem_cache_destroy(inode_entry_slab);
+ kmem_cache_destroy(f2fs_inode_entry_slab);
}
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index eedfa2a13786..7f955c4e86a4 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -586,7 +586,7 @@ int f2fs_add_regular_entry(struct inode *dir, const struct
qstr *new_name,
return err;
}
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode)
{
struct qstr new_name;
@@ -610,7 +610,7 @@ int __f2fs_do_add_link(struct inode *dir, struct
fscrypt_name *fname,
* Caller should grab and release a rwsem by calling f2fs_lock_op() and
* f2fs_unlock_op().
*/
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode)
{
struct fscrypt_name fname;
@@ -639,7 +639,7 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name,
} else if (IS_ERR(page)) {
err = PTR_ERR(page);
} else {
- err = __f2fs_do_add_link(dir, , inode, ino, mode);
+ err = f2fs_add_dentry(dir, , inode, ino, mode);
}
fscrypt_free_filename();
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ba1063ed39eb..f167d01443fe 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2626,7 +2626,7 @@ static inline int get_inline_xattr_addrs(struct inode
*inode)
return F2FS_I(inode)->i_inline_xattr_size;
}
-#define get_inode_mode(i) \
+#define f2fs_get_inode_mode(i) \
((is_inode_flag_set(i, FI_ACL_MODE)) ? \
(F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
@@ -2744,9 +2744,9 @@ void f2fs_update_dentry(nid_t ino, umode_t mode, struct
f2fs_dentry_ptr *d,
int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,
const struct qstr *orig_name,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode);
void f2fs_delete_entry(struct f2fs_dir_entry *dentry, struct page *page,
struct inode *dir, struct inode *inode);
@@ -2755,7 +2755,7 @@ bool f2fs_empty_dir(struct inode *dir);
static inline int f2fs_add_link(struct dentry *dentry, struct inode *inode)
{
- return __f2fs_add_link(d_inode(dentry->d_parent), >d_name,
+ return f2fs_do_add_link(d_inode(dentry->d_parent), >d_name,
inode, inode->i_ino, inode->i_mode);
}
@@ -3190,7 +3190,7 @@ extern const struct inode_operations
f2fs_dir_inode_operations;
extern const struct inode_operations f2fs_symlink_inode_operations;
extern const struct inode_operations f2fs_encrypted_symlink_inode_operations;
extern const struct inode_operations f2fs_special_inode_operations;
-extern struct kmem_cache *inode_entry_slab;
+extern struct kmem_cache
Re: [PATCH 3/3] f2fs: clean up symbol namespace
Hi Chao,
Thank you for the work.
I resolved some conflicts and modified some function names.
Please take a look at this.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/dir.c| 6 +++---
fs/f2fs/f2fs.h | 10 +-
fs/f2fs/file.c | 2 +-
fs/f2fs/gc.c | 4 ++--
fs/f2fs/namei.c | 4 ++--
fs/f2fs/recovery.c | 2 +-
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 078c2d5c5b2e..8eb184c3de84 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -24,7 +24,7 @@
#include
static struct kmem_cache *ino_entry_slab;
-struct kmem_cache *inode_entry_slab;
+struct kmem_cache *f2fs_inode_entry_slab;
void f2fs_stop_checkpoint(struct f2fs_sb_info *sbi, bool end_io)
{
@@ -1490,9 +1490,9 @@ int __init f2fs_create_checkpoint_caches(void)
sizeof(struct ino_entry));
if (!ino_entry_slab)
return -ENOMEM;
- inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
+ f2fs_inode_entry_slab = f2fs_kmem_cache_create("f2fs_inode_entry",
sizeof(struct inode_entry));
- if (!inode_entry_slab) {
+ if (!f2fs_inode_entry_slab) {
kmem_cache_destroy(ino_entry_slab);
return -ENOMEM;
}
@@ -1502,5 +1502,5 @@ int __init f2fs_create_checkpoint_caches(void)
void f2fs_destroy_checkpoint_caches(void)
{
kmem_cache_destroy(ino_entry_slab);
- kmem_cache_destroy(inode_entry_slab);
+ kmem_cache_destroy(f2fs_inode_entry_slab);
}
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index eedfa2a13786..7f955c4e86a4 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -586,7 +586,7 @@ int f2fs_add_regular_entry(struct inode *dir, const struct
qstr *new_name,
return err;
}
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode)
{
struct qstr new_name;
@@ -610,7 +610,7 @@ int __f2fs_do_add_link(struct inode *dir, struct
fscrypt_name *fname,
* Caller should grab and release a rwsem by calling f2fs_lock_op() and
* f2fs_unlock_op().
*/
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode)
{
struct fscrypt_name fname;
@@ -639,7 +639,7 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name,
} else if (IS_ERR(page)) {
err = PTR_ERR(page);
} else {
- err = __f2fs_do_add_link(dir, , inode, ino, mode);
+ err = f2fs_add_dentry(dir, , inode, ino, mode);
}
fscrypt_free_filename();
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ba1063ed39eb..f167d01443fe 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2626,7 +2626,7 @@ static inline int get_inline_xattr_addrs(struct inode
*inode)
return F2FS_I(inode)->i_inline_xattr_size;
}
-#define get_inode_mode(i) \
+#define f2fs_get_inode_mode(i) \
((is_inode_flag_set(i, FI_ACL_MODE)) ? \
(F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
@@ -2744,9 +2744,9 @@ void f2fs_update_dentry(nid_t ino, umode_t mode, struct
f2fs_dentry_ptr *d,
int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,
const struct qstr *orig_name,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_do_add_link(struct inode *dir, struct fscrypt_name *fname,
+int f2fs_add_dentry(struct inode *dir, struct fscrypt_name *fname,
struct inode *inode, nid_t ino, umode_t mode);
-int __f2fs_add_link(struct inode *dir, const struct qstr *name,
+int f2fs_do_add_link(struct inode *dir, const struct qstr *name,
struct inode *inode, nid_t ino, umode_t mode);
void f2fs_delete_entry(struct f2fs_dir_entry *dentry, struct page *page,
struct inode *dir, struct inode *inode);
@@ -2755,7 +2755,7 @@ bool f2fs_empty_dir(struct inode *dir);
static inline int f2fs_add_link(struct dentry *dentry, struct inode *inode)
{
- return __f2fs_add_link(d_inode(dentry->d_parent), >d_name,
+ return f2fs_do_add_link(d_inode(dentry->d_parent), >d_name,
inode, inode->i_ino, inode->i_mode);
}
@@ -3190,7 +3190,7 @@ extern const struct inode_operations
f2fs_dir_inode_operations;
extern const struct inode_operations f2fs_symlink_inode_operations;
extern const struct inode_operations f2fs_encrypted_symlink_inode_operations;
extern const struct inode_operations f2fs_special_inode_operations;
-extern struct kmem_cache *inode_entry_slab;
+extern struct kmem_cache
Re: Status of aspeed-bmc-opp-firestone (IBM S822LC)
Hi Paul, On Wed, 30 May 2018, at 00:23, Paul Menzel wrote: > Dear Joel, dear Linux folks, > > > We have an IBM S822LC system (Firestone(?)). Building of OpenBMC > currently fails, as the not everything was ported from dev-4.10 to > dev-4.13 [1], and therefore a file cannot be found. > > Looking at upstream Linux, there are BMCs for Power 8 systems, like > Palmetto, included. > > ``` > $ ls arch/arm/boot/dts/aspeed-bmc-opp-* > arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts > arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > ``` > > Does somebody know, why Firestone was not upstreamed? Is somebody > working on upstreaming it? If not, do you have scripts to port such > work? Manually cherry-picking stuff in this case is hard, as there are a > lot of conflicts. Firestone was never really maintained. We hacked around with it for a bit, but nothing concrete really came of it. As far as I'm aware, no-one is working on upstreaming it. Also, I don't think there were any scripts used in the process, so it's going to be some drudge work to get things running. Sorry that I don't have a more positive answer. Maybe someone else knows better. Cheers, Andrew
Re: Status of aspeed-bmc-opp-firestone (IBM S822LC)
Hi Paul, On Wed, 30 May 2018, at 00:23, Paul Menzel wrote: > Dear Joel, dear Linux folks, > > > We have an IBM S822LC system (Firestone(?)). Building of OpenBMC > currently fails, as the not everything was ported from dev-4.10 to > dev-4.13 [1], and therefore a file cannot be found. > > Looking at upstream Linux, there are BMCs for Power 8 systems, like > Palmetto, included. > > ``` > $ ls arch/arm/boot/dts/aspeed-bmc-opp-* > arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts > arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > ``` > > Does somebody know, why Firestone was not upstreamed? Is somebody > working on upstreaming it? If not, do you have scripts to port such > work? Manually cherry-picking stuff in this case is hard, as there are a > lot of conflicts. Firestone was never really maintained. We hacked around with it for a bit, but nothing concrete really came of it. As far as I'm aware, no-one is working on upstreaming it. Also, I don't think there were any scripts used in the process, so it's going to be some drudge work to get things running. Sorry that I don't have a more positive answer. Maybe someone else knows better. Cheers, Andrew
[PATCH] usb: dwc2: gadget: fix missing process for isoc descriptor dma mode
If it's the first request to queue, and we are using descriptor dma mode
for isoc transfer, we only need to add the request to the queue, and it
will be processed in the future nak interrupt handler.
Signed-off-by: Zeng Tao
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f0d9ccf..48e3a48c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1365,6 +1365,9 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, struct
usb_request *req,
return 0;
}
+ if (using_desc_dma(hs))
+ return 0;
+
/* Update current frame number value. */
hs->frame_number = dwc2_hsotg_read_frameno(hs);
while (dwc2_gadget_target_frame_elapsed(hs_ep)) {
--
2.7.4
[PATCH] usb: dwc2: gadget: fix missing process for isoc descriptor dma mode
If it's the first request to queue, and we are using descriptor dma mode
for isoc transfer, we only need to add the request to the queue, and it
will be processed in the future nak interrupt handler.
Signed-off-by: Zeng Tao
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f0d9ccf..48e3a48c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1365,6 +1365,9 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, struct
usb_request *req,
return 0;
}
+ if (using_desc_dma(hs))
+ return 0;
+
/* Update current frame number value. */
hs->frame_number = dwc2_hsotg_read_frameno(hs);
while (dwc2_gadget_target_frame_elapsed(hs_ep)) {
--
2.7.4
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:44 PM, Eric Dumazet wrote:
>
> And I will add this simple fix, this really should address your initial
> concern much better.
>
> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem,
> int order,
> {
> struct page *page;
>
> + if (order)
> + gfp_mask |= __GFP_NORETRY;
and also gfp_mask &= ~__GFP_DIRECT_RECLAIM
> page = alloc_pages_node(node, gfp_mask, order);
> if (!page) {
> page = alloc_pages(gfp_mask, order);
>
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:44 PM, Eric Dumazet wrote:
>
> And I will add this simple fix, this really should address your initial
> concern much better.
>
> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem,
> int order,
> {
> struct page *page;
>
> + if (order)
> + gfp_mask |= __GFP_NORETRY;
and also gfp_mask &= ~__GFP_DIRECT_RECLAIM
> page = alloc_pages_node(node, gfp_mask, order);
> if (!page) {
> page = alloc_pages(gfp_mask, order);
>
RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > > Jacob Pan wrote: > > > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > > Jean-Philippe Brucker wrote: > > > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > > [...] > > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > > aligned or the format of the PASID table? Are these all > > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > > maybe we could note that and the spec which defines them when > we > > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > > understand how we'll match a user provided PASID table to the > > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > > guest > > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > > Maybe this information could be part of the data passed to > userspace > > > > > about IOMMU table formats and features? They're not part of this > > > > > series, but I think we wanted to communicate IOMMU-specific > features > > > > > via sysfs. > > > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > > can match IOMMU model and features. > > > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > > interface. Are we suggesting that the /only/ way to make use of the > > > internal IOMMU API here is to have a user provided opaque pasid table > > > that we can't even do minimal compatibility sanity testing on and we > > > simply hope that hardware covers all the fault conditions without > > > taking the host down with it? I guess we have to assume the latter > > > since the user has full control of the table, but I have a hard time > > > getting past lack of internal ability to use the interface and no > > > ability to provide even the slimmest sanity testing. Thanks, > > > > > > > checking size, alignment, ... is OK, which I think is already considered > > by vendor IOMMU driver. However sanity testing table format might > > be difficult. The initial table provided by guest is likely just all ZEROs. > > whatever format violation may be caught only when a PASID entry > > is updated... > > There's sanity testing the actual contents of the table, which I agree > would be difficult and would likely require some sort of shadowing at > additional overhead, but what about even basic consistency checking? > For example, is it possible that due to hardware variations a user > might generate a table which works on some systems but not others? > What > if two table formats are sufficiently similar that the IOMMU driver > puts an incompatible table in place but it continuously generates > faults, how do we debug that? As an intermediary in this whole process > I'd really rather be able to identify that the user claims to be > providing a TypeA table but the IOMMU only supports TypeB, so clearly > this won't work. I don't see that we have that capability. Thanks, > I remember we ever discussed to define some vendor/model ID, which can be retrieved by user space and then passed back when doing table binding. Then above simple model matching check can be done accordingly. It is actually a basic requirement when using virtio-iommu, same driver expecting to work on all vendor IOMMUs. However I don't remember whether/where that logic is implemented in this series (especially when there are two tracks moving in parallel). I'll leave to Jacob/Jean to further comment. Thanks Kevin
RE: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 30, 2018 11:18 AM > > On Wed, 30 May 2018 01:41:43 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > > Jacob Pan wrote: > > > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > > Jean-Philippe Brucker wrote: > > > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > > [...] > > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > > aligned or the format of the PASID table? Are these all > > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > > maybe we could note that and the spec which defines them when > we > > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > > understand how we'll match a user provided PASID table to the > > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > > guest > > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > > Maybe this information could be part of the data passed to > userspace > > > > > about IOMMU table formats and features? They're not part of this > > > > > series, but I think we wanted to communicate IOMMU-specific > features > > > > > via sysfs. > > > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > > can match IOMMU model and features. > > > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > > interface. Are we suggesting that the /only/ way to make use of the > > > internal IOMMU API here is to have a user provided opaque pasid table > > > that we can't even do minimal compatibility sanity testing on and we > > > simply hope that hardware covers all the fault conditions without > > > taking the host down with it? I guess we have to assume the latter > > > since the user has full control of the table, but I have a hard time > > > getting past lack of internal ability to use the interface and no > > > ability to provide even the slimmest sanity testing. Thanks, > > > > > > > checking size, alignment, ... is OK, which I think is already considered > > by vendor IOMMU driver. However sanity testing table format might > > be difficult. The initial table provided by guest is likely just all ZEROs. > > whatever format violation may be caught only when a PASID entry > > is updated... > > There's sanity testing the actual contents of the table, which I agree > would be difficult and would likely require some sort of shadowing at > additional overhead, but what about even basic consistency checking? > For example, is it possible that due to hardware variations a user > might generate a table which works on some systems but not others? > What > if two table formats are sufficiently similar that the IOMMU driver > puts an incompatible table in place but it continuously generates > faults, how do we debug that? As an intermediary in this whole process > I'd really rather be able to identify that the user claims to be > providing a TypeA table but the IOMMU only supports TypeB, so clearly > this won't work. I don't see that we have that capability. Thanks, > I remember we ever discussed to define some vendor/model ID, which can be retrieved by user space and then passed back when doing table binding. Then above simple model matching check can be done accordingly. It is actually a basic requirement when using virtio-iommu, same driver expecting to work on all vendor IOMMUs. However I don't remember whether/where that logic is implemented in this series (especially when there are two tracks moving in parallel). I'll leave to Jacob/Jean to further comment. Thanks Kevin
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:34 PM, Eric Dumazet wrote:
> I will test :
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index
> 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097
> 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -43,12 +43,13 @@
> #include "fw.h"
>
> /*
> - * We allocate in page size (default 4KB on many archs) chunks to avoid high
> - * order memory allocations in fragmented/high usage memory situation.
> + * We allocate in as big chunks as we can, up to a maximum of 256 KB
> + * per chunk. Note that the chunks are not necessarily in contiguous
> + * physical memory.
> */
> enum {
> - MLX4_ICM_ALLOC_SIZE = PAGE_SIZE,
> - MLX4_TABLE_CHUNK_SIZE = PAGE_SIZE,
> + MLX4_ICM_ALLOC_SIZE = 1 << 18,
> + MLX4_TABLE_CHUNK_SIZE = 1 << 18
> };
>
> static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk
> *chunk)
>
And I will add this simple fix, this really should address your initial concern
much better.
@@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, int
order,
{
struct page *page;
+ if (order)
+ gfp_mask |= __GFP_NORETRY;
page = alloc_pages_node(node, gfp_mask, order);
if (!page) {
page = alloc_pages(gfp_mask, order);
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/29/2018 11:34 PM, Eric Dumazet wrote:
> I will test :
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index
> 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097
> 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -43,12 +43,13 @@
> #include "fw.h"
>
> /*
> - * We allocate in page size (default 4KB on many archs) chunks to avoid high
> - * order memory allocations in fragmented/high usage memory situation.
> + * We allocate in as big chunks as we can, up to a maximum of 256 KB
> + * per chunk. Note that the chunks are not necessarily in contiguous
> + * physical memory.
> */
> enum {
> - MLX4_ICM_ALLOC_SIZE = PAGE_SIZE,
> - MLX4_TABLE_CHUNK_SIZE = PAGE_SIZE,
> + MLX4_ICM_ALLOC_SIZE = 1 << 18,
> + MLX4_TABLE_CHUNK_SIZE = 1 << 18
> };
>
> static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk
> *chunk)
>
And I will add this simple fix, this really should address your initial concern
much better.
@@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, int
order,
{
struct page *page;
+ if (order)
+ gfp_mask |= __GFP_NORETRY;
page = alloc_pages_node(node, gfp_mask, order);
if (!page) {
page = alloc_pages(gfp_mask, order);
Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.
Signed-off-by: Kevin Easton
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com
Is this patch going anywhere ?
The patch fixes CVE-2018-1118. It would be useful to understand if and when
this problem is going to be fixed.
Thanks,
Guenter
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..1b84dcff 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
/* Create a new message. */
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
{
- struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
+ struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
node->vq = vq;
As I pointed out, we don't need to init the whole structure. The proper
fix is thus (I think) below.
Could you use your testing infrastructure to confirm this fixes the issue?
Sorry, I don't have the means to test the fix.
Guenter
Thanks!
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e941224..58d9aec90afb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct
vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(>msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.
Signed-off-by: Kevin Easton
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com
Is this patch going anywhere ?
The patch fixes CVE-2018-1118. It would be useful to understand if and when
this problem is going to be fixed.
Thanks,
Guenter
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..1b84dcff 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
/* Create a new message. */
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
{
- struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
+ struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
node->vq = vq;
As I pointed out, we don't need to init the whole structure. The proper
fix is thus (I think) below.
Could you use your testing infrastructure to confirm this fixes the issue?
Sorry, I don't have the means to test the fix.
Guenter
Thanks!
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e941224..58d9aec90afb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct
vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(>msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
Re: [PATCH] mm: Change return type to vm_fault_t
On Tue, May 29, 2018 at 11:04 PM, Matthew Wilcox wrote:
> On Tue, May 29, 2018 at 09:25:05PM +0530, Souptick Joarder wrote:
>> On Tue, May 29, 2018 at 8:20 PM, Matthew Wilcox wrote:
>> > On Tue, May 29, 2018 at 08:01:26PM +0530, Souptick Joarder wrote:
>> >> Use new return type vm_fault_t for fault handler. For
>> >> now, this is just documenting that the function returns
>> >> a VM_FAULT value rather than an errno. Once all instances
>> >> are converted, vm_fault_t will become a distinct type.
>> >
>> > I don't believe you've checked this with sparse.
>> >
>> >> @@ -802,7 +802,8 @@ int fixup_user_fault(struct task_struct *tsk, struct
>> >> mm_struct *mm,
>> >>bool *unlocked)
>> >> {
>> >> struct vm_area_struct *vma;
>> >> - int ret, major = 0;
>> >> + int major = 0;
>> >> + vm_fault_t ret;
>> >>
>> >> if (unlocked)
>> >> fault_flags |= FAULT_FLAG_ALLOW_RETRY;
>> >
>> > ...
>> > major |= ret & VM_FAULT_MAJOR;
>> >
>> > That should be throwing a warning.
>>
>> Sorry, but I verified again and didn't see similar warnings.
>>
>> steps followed -
>>
>> apply the patch
>> make c=2 -j4 ( build for x86_64)
>> looking for warnings in files because of this patch.
>>
>> The only error I am seeing "error: undefined identifier '__COUNTER__' "
>> which is pointing to BUG(). There are few warnings but those are not
>> related to this patch.
>>
>> In my test tree the final patch to create new vm_fault_t type is
>> already applied.
>>
>> Do you want me to verify in some other way ?
>
> I see:
>
> mm/gup.c:817:15: warning: invalid assignment: |=
> mm/gup.c:817:15:left side has type int
> mm/gup.c:817:15:right side has type restricted vm_fault_t
>
> are you building with 'c=2' or 'C=2'?
Building with C=2.
Do I need to enable any separate FLAG ?
Re: [PATCH] mm: Change return type to vm_fault_t
On Tue, May 29, 2018 at 11:04 PM, Matthew Wilcox wrote:
> On Tue, May 29, 2018 at 09:25:05PM +0530, Souptick Joarder wrote:
>> On Tue, May 29, 2018 at 8:20 PM, Matthew Wilcox wrote:
>> > On Tue, May 29, 2018 at 08:01:26PM +0530, Souptick Joarder wrote:
>> >> Use new return type vm_fault_t for fault handler. For
>> >> now, this is just documenting that the function returns
>> >> a VM_FAULT value rather than an errno. Once all instances
>> >> are converted, vm_fault_t will become a distinct type.
>> >
>> > I don't believe you've checked this with sparse.
>> >
>> >> @@ -802,7 +802,8 @@ int fixup_user_fault(struct task_struct *tsk, struct
>> >> mm_struct *mm,
>> >>bool *unlocked)
>> >> {
>> >> struct vm_area_struct *vma;
>> >> - int ret, major = 0;
>> >> + int major = 0;
>> >> + vm_fault_t ret;
>> >>
>> >> if (unlocked)
>> >> fault_flags |= FAULT_FLAG_ALLOW_RETRY;
>> >
>> > ...
>> > major |= ret & VM_FAULT_MAJOR;
>> >
>> > That should be throwing a warning.
>>
>> Sorry, but I verified again and didn't see similar warnings.
>>
>> steps followed -
>>
>> apply the patch
>> make c=2 -j4 ( build for x86_64)
>> looking for warnings in files because of this patch.
>>
>> The only error I am seeing "error: undefined identifier '__COUNTER__' "
>> which is pointing to BUG(). There are few warnings but those are not
>> related to this patch.
>>
>> In my test tree the final patch to create new vm_fault_t type is
>> already applied.
>>
>> Do you want me to verify in some other way ?
>
> I see:
>
> mm/gup.c:817:15: warning: invalid assignment: |=
> mm/gup.c:817:15:left side has type int
> mm/gup.c:817:15:right side has type restricted vm_fault_t
>
> are you building with 'c=2' or 'C=2'?
Building with C=2.
Do I need to enable any separate FLAG ?
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/25/2018 10:23 AM, David Miller wrote: > From: Qing Huang > Date: Wed, 23 May 2018 16:22:46 -0700 > >> When a system is under memory presure (high usage with fragments), >> the original 256KB ICM chunk allocations will likely trigger kernel >> memory management to enter slow path doing memory compact/migration >> ops in order to complete high order memory allocations. >> >> When that happens, user processes calling uverb APIs may get stuck >> for more than 120s easily even though there are a lot of free pages >> in smaller chunks available in the system. >> >> Syslog: >> ... >> Dec 10 09:04:51 slcc03db02 kernel: [397078.572732] INFO: task >> oracle_205573_e:205573 blocked for more than 120 seconds. >> ... >> >> With 4KB ICM chunk size on x86_64 arch, the above issue is fixed. >> >> However in order to support smaller ICM chunk size, we need to fix >> another issue in large size kcalloc allocations. >> >> E.g. >> Setting log_num_mtt=30 requires 1G mtt entries. With the 4KB ICM chunk >> size, each ICM chunk can only hold 512 mtt entries (8 bytes for each mtt >> entry). So we need a 16MB allocation for a table->icm pointer array to >> hold 2M pointers which can easily cause kcalloc to fail. >> >> The solution is to use kvzalloc to replace kcalloc which will fall back >> to vmalloc automatically if kmalloc fails. >> >> Signed-off-by: Qing Huang >> Acked-by: Daniel Jurgens >> Reviewed-by: Zhu Yanjun > > Applied, thanks. > I must say this patch causes regressions here. KASAN is not happy. It looks that you guys did not really looked at mlx4_alloc_icm() This function is properly handling high order allocations with fallbacks to order-0 pages under high memory pressure. BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] Read of size 4 at addr 8817df584f68 by task qp_listing_test/92585 CPU: 38 PID: 92585 Comm: qp_listing_test Tainted: G O Call Trace: [] dump_stack+0x4d/0x72 [] print_address_description+0x6f/0x260 [] kasan_report+0x257/0x370 [] __asan_report_load4_noabort+0x19/0x20 [] to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] [] mlx4_ib_query_qp+0x1213/0x1660 [mlx4_ib] [] qpstat_print_qp+0x13b/0x500 [ib_uverbs] [] qpstat_seq_show+0x4a/0xb0 [ib_uverbs] [] seq_read+0xa9c/0x1230 [] proc_reg_read+0xc1/0x180 [] __vfs_read+0xe8/0x730 [] vfs_read+0xf7/0x300 [] SyS_read+0xd2/0x1b0 [] do_syscall_64+0x186/0x420 [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7f851a7bb30d RSP: 002b:7ffd09a758c0 EFLAGS: 0293 ORIG_RAX: RAX: ffda RBX: 7f84ff959440 RCX: 7f851a7bb30d RDX: 0003fc00 RSI: 7f84ff60a000 RDI: 000b RBP: 7ffd09a75900 R08: R09: R10: 0022 R11: 0293 R12: R13: 0003 R14: 0003 R15: 7f84ff60a000 Allocated by task 4488: save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x101/0x5e0 ib_register_device+0xc03/0x1250 [ib_core] mlx4_ib_add+0x27d6/0x4dd0 [mlx4_ib] mlx4_add_device+0xa9/0x340 [mlx4_core] mlx4_register_interface+0x16e/0x390 [mlx4_core] xhci_pci_remove+0x7a/0x180 [xhci_pci] do_one_initcall+0xa0/0x230 do_init_module+0x1b9/0x5a4 load_module+0x63e6/0x94c0 SYSC_init_module+0x1a4/0x1c0 SyS_init_module+0xe/0x10 do_syscall_64+0x186/0x420 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Freed by task 0: (stack is not available) The buggy address belongs to the object at 8817df584f40 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 8 bytes to the right of 32-byte region [8817df584f40, 8817df584f60) The buggy address belongs to the page: page:ea005f7d6100 count:1 mapcount:0 mapping:8817df584000 index:0x8817df584fc1 flags: 0x8800100(slab) raw: 08800100 8817df584000 8817df584fc1 0001003f raw: ea005f3ac0a0 ea005c476760 8817fec00900 883ff78d26c0 page dumped because: kasan: bad access detected page->mem_cgroup:883ff78d26c0 Memory state around the buggy address: 8817df584e00: 00 03 fc fc fc fc fc fc 00 03 fc fc fc fc fc fc 8817df584e80: 00 00 00 04 fc fc fc fc 00 00 00 fc fc fc fc fc >8817df584f00: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc ^ 8817df584f80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc 8817df585000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb I will test : diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c index 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097 100644 --- a/drivers/net/ethernet/mellanox/mlx4/icm.c +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c @@ -43,12 +43,13 @@ #include "fw.h" /* - * We allocate in page size (default 4KB on many archs) chunks to avoid high - * order memory allocations in fragmented/high usage memory situation. + * We allocate in as big
Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
On 05/25/2018 10:23 AM, David Miller wrote: > From: Qing Huang > Date: Wed, 23 May 2018 16:22:46 -0700 > >> When a system is under memory presure (high usage with fragments), >> the original 256KB ICM chunk allocations will likely trigger kernel >> memory management to enter slow path doing memory compact/migration >> ops in order to complete high order memory allocations. >> >> When that happens, user processes calling uverb APIs may get stuck >> for more than 120s easily even though there are a lot of free pages >> in smaller chunks available in the system. >> >> Syslog: >> ... >> Dec 10 09:04:51 slcc03db02 kernel: [397078.572732] INFO: task >> oracle_205573_e:205573 blocked for more than 120 seconds. >> ... >> >> With 4KB ICM chunk size on x86_64 arch, the above issue is fixed. >> >> However in order to support smaller ICM chunk size, we need to fix >> another issue in large size kcalloc allocations. >> >> E.g. >> Setting log_num_mtt=30 requires 1G mtt entries. With the 4KB ICM chunk >> size, each ICM chunk can only hold 512 mtt entries (8 bytes for each mtt >> entry). So we need a 16MB allocation for a table->icm pointer array to >> hold 2M pointers which can easily cause kcalloc to fail. >> >> The solution is to use kvzalloc to replace kcalloc which will fall back >> to vmalloc automatically if kmalloc fails. >> >> Signed-off-by: Qing Huang >> Acked-by: Daniel Jurgens >> Reviewed-by: Zhu Yanjun > > Applied, thanks. > I must say this patch causes regressions here. KASAN is not happy. It looks that you guys did not really looked at mlx4_alloc_icm() This function is properly handling high order allocations with fallbacks to order-0 pages under high memory pressure. BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] Read of size 4 at addr 8817df584f68 by task qp_listing_test/92585 CPU: 38 PID: 92585 Comm: qp_listing_test Tainted: G O Call Trace: [] dump_stack+0x4d/0x72 [] print_address_description+0x6f/0x260 [] kasan_report+0x257/0x370 [] __asan_report_load4_noabort+0x19/0x20 [] to_rdma_ah_attr+0x808/0x9e0 [mlx4_ib] [] mlx4_ib_query_qp+0x1213/0x1660 [mlx4_ib] [] qpstat_print_qp+0x13b/0x500 [ib_uverbs] [] qpstat_seq_show+0x4a/0xb0 [ib_uverbs] [] seq_read+0xa9c/0x1230 [] proc_reg_read+0xc1/0x180 [] __vfs_read+0xe8/0x730 [] vfs_read+0xf7/0x300 [] SyS_read+0xd2/0x1b0 [] do_syscall_64+0x186/0x420 [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7f851a7bb30d RSP: 002b:7ffd09a758c0 EFLAGS: 0293 ORIG_RAX: RAX: ffda RBX: 7f84ff959440 RCX: 7f851a7bb30d RDX: 0003fc00 RSI: 7f84ff60a000 RDI: 000b RBP: 7ffd09a75900 R08: R09: R10: 0022 R11: 0293 R12: R13: 0003 R14: 0003 R15: 7f84ff60a000 Allocated by task 4488: save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x101/0x5e0 ib_register_device+0xc03/0x1250 [ib_core] mlx4_ib_add+0x27d6/0x4dd0 [mlx4_ib] mlx4_add_device+0xa9/0x340 [mlx4_core] mlx4_register_interface+0x16e/0x390 [mlx4_core] xhci_pci_remove+0x7a/0x180 [xhci_pci] do_one_initcall+0xa0/0x230 do_init_module+0x1b9/0x5a4 load_module+0x63e6/0x94c0 SYSC_init_module+0x1a4/0x1c0 SyS_init_module+0xe/0x10 do_syscall_64+0x186/0x420 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Freed by task 0: (stack is not available) The buggy address belongs to the object at 8817df584f40 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 8 bytes to the right of 32-byte region [8817df584f40, 8817df584f60) The buggy address belongs to the page: page:ea005f7d6100 count:1 mapcount:0 mapping:8817df584000 index:0x8817df584fc1 flags: 0x8800100(slab) raw: 08800100 8817df584000 8817df584fc1 0001003f raw: ea005f3ac0a0 ea005c476760 8817fec00900 883ff78d26c0 page dumped because: kasan: bad access detected page->mem_cgroup:883ff78d26c0 Memory state around the buggy address: 8817df584e00: 00 03 fc fc fc fc fc fc 00 03 fc fc fc fc fc fc 8817df584e80: 00 00 00 04 fc fc fc fc 00 00 00 fc fc fc fc fc >8817df584f00: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc ^ 8817df584f80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc 8817df585000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb I will test : diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c index 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097 100644 --- a/drivers/net/ethernet/mellanox/mlx4/icm.c +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c @@ -43,12 +43,13 @@ #include "fw.h" /* - * We allocate in page size (default 4KB on many archs) chunks to avoid high - * order memory allocations in fragmented/high usage memory situation. + * We allocate in as big
RE: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64 When reading the code, I feel it is more appropriate to add macro control here. -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Tuesday, May 29, 2018 11:45 PM To: Nixiaoming Cc: catalin.mari...@arm.com; ard.biesheu...@linaro.org; marc.zyng...@arm.com; james.mo...@arm.com; kristina.martse...@arm.com; steve.cap...@arm.com; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; a...@linux-foundation.org; vba...@suse.cz; mho...@suse.com; dave.han...@linux.intel.com; dan.j.willi...@intel.com; kirill.shute...@linux.intel.com; zhang@linux.alibaba.com; schwidef...@de.ibm.com; heiko.carst...@de.ibm.com; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; x...@kernel.org; linux-s...@vger.kernel.org Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote: > mark_rodata_ro is only called by the function mark_readonly when > CONFIG_STRICT_KERNEL_RWX=y, > if CONFIG_STRICT_KERNEL_RWX is not set > a compile warning may be triggered: unused function How are you achieving this configuration? In our Kconfig we select this unconditionally. Will
RE: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64 When reading the code, I feel it is more appropriate to add macro control here. -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Tuesday, May 29, 2018 11:45 PM To: Nixiaoming Cc: catalin.mari...@arm.com; ard.biesheu...@linaro.org; marc.zyng...@arm.com; james.mo...@arm.com; kristina.martse...@arm.com; steve.cap...@arm.com; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; a...@linux-foundation.org; vba...@suse.cz; mho...@suse.com; dave.han...@linux.intel.com; dan.j.willi...@intel.com; kirill.shute...@linux.intel.com; zhang@linux.alibaba.com; schwidef...@de.ibm.com; heiko.carst...@de.ibm.com; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; x...@kernel.org; linux-s...@vger.kernel.org Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote: > mark_rodata_ro is only called by the function mark_readonly when > CONFIG_STRICT_KERNEL_RWX=y, > if CONFIG_STRICT_KERNEL_RWX is not set > a compile warning may be triggered: unused function How are you achieving this configuration? In our Kconfig we select this unconditionally. Will
Re: scsi/qla2xxx: BUG_ON(blk_queued_rq(req) is triggered in blk_finish_request
Hi Himanshu
Thanks for your kindly response.
On 05/30/2018 01:44 AM, Madhani, Himanshu wrote:
> Thanks for the information. I was out for couple days. Still working through
> my emails.
>
> Without core dump shared with us, things become hard to debug. We'll take a
> look at this data.
>
> Also, if you have any reproducer test case, Can you share that with us so
> that we can try to trigger It internally and see if we have better luck
> debugging that.
This issue occurred in customer's environment twice till now, there is no
reproduce steps.
If you have time, would you please look at our analysis to see whether it is
reasonable ?
The kernel is not newest, but there should be the same issue in mainline with
scsi + block legacy
The key point here is:
when the aborted command returns in irq context, it will invoke scsi_done, then
blk_complete_request.
however, the scsi recovery context could clear the ATOM_COMPLETE and requeue
the request before irq
context get it.
Thanks
Jianchao
>
> On 5/28/18, 6:11 PM, "jianchao.wang" wrote:
>
> Hi Himanshu
>
> do you need any other information ?
>
> Thanks
> Jianchao
>
> On 05/25/2018 02:48 PM, jianchao.wang wrote:
> > Hi Himanshu
> >
> > I'm afraid I cannot provide you the vmcore file, it is from our
> customer.
> > If any information needed in the vmcore, I could provide with you.
> >
> > In this scene, there are two contexts:
> > 1. the irq context, scsi_done() from qla2x00_sp_compl()
> > 2. the kworker context, scmd_eh_abort_handler which invokes the
> > qla2xxx_eh_abort()
> >
> > Let's see the irq context.
> > scsi_done() will invoke the blk_complete_request().
> > In common case, the REQ_ATOM_COMPLETE should have been set by
> > blk_rq_check_expired() when the request was confirmed timeout. So
> > __blk_complete_request() will not be invoked.
> >
> > On the other hand, in the kworker context, scmd_eh_abort_handler() will
> do some
> > other things on this aborted request.
> >
> > rtn = scsi_try_to_abort_cmd(sdev->host->hostt, scmd);
> > if (rtn == SUCCESS) {
> > set_host_byte(scmd, DID_TIME_OUT)
> > if (scsi_host_eh_past_deadline(sdev->host)) {
> >
> > } else if (!scsi_noretry_cmd(scmd) &&
> > (++scmd->retries <= scmd->allowed)) {
> > scsi_queue_insert(scmd, SCSI_MLQUEUE_EH_RETRY)
> > }
> >
> > }
> > The host type of the result will set to DID_TIME_OUT.
> scsi_noretry_cmd() will
> > return false and scsi_queue_insert() will be invoked, finally the
> > blk_requeue_request().
> >
> > blk_requeue_request() will clear the REQ_ATOM_COMPLETE and queue the
> request on
> > request_queue->queue_head.
> >
> > There could be a race between these two contexts:
> > what if the blk_clear_rq_complete() in kworker context is invoked
> before the
> > blk_mark_rq_complete() in irq context ?
> >
> > BLK_SOFTIRQ will be raised by __blk_complete_request() in irq context.
> Then the
> > scsi_softirq_done() will be invoked. At the moment, the request has been
> > requeued by kworker context and scsi_cmnd->result is set 0. On the cpu
> of the
> > irq context, the blk_finish_request() will be invoked finally, and
> panic comes
> > up due to BUG_ON(blk_queued_rq(req)
> >
> > Here is the dmesg log.
> > [4937745.180213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.180655] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181059] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.181514] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181636] [ cut here ]
> > [4937745.181900] kernel BUG at block/blk-core.c:2601!
> > [4937745.182095] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.182338] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183046] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.183213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183844] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.184038] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.184919] invalid opcode: [#1] SMP
> > [4937745.185173] Modules linked in: ...
> > [4937745.188237] CPU: 18 PID: 0 Comm: swapper/18 Not tainted
> 4.1.12-61.1.9.el6uek.x86_64 #2
> > [4937745.188691] Hardware name: Oracle Corporation SUN BLADE X4-2B
> /BD,ASSY,PCB,X4-2B , BIOS 28010200 01/16/2014
>
Re: scsi/qla2xxx: BUG_ON(blk_queued_rq(req) is triggered in blk_finish_request
Hi Himanshu
Thanks for your kindly response.
On 05/30/2018 01:44 AM, Madhani, Himanshu wrote:
> Thanks for the information. I was out for couple days. Still working through
> my emails.
>
> Without core dump shared with us, things become hard to debug. We'll take a
> look at this data.
>
> Also, if you have any reproducer test case, Can you share that with us so
> that we can try to trigger It internally and see if we have better luck
> debugging that.
This issue occurred in customer's environment twice till now, there is no
reproduce steps.
If you have time, would you please look at our analysis to see whether it is
reasonable ?
The kernel is not newest, but there should be the same issue in mainline with
scsi + block legacy
The key point here is:
when the aborted command returns in irq context, it will invoke scsi_done, then
blk_complete_request.
however, the scsi recovery context could clear the ATOM_COMPLETE and requeue
the request before irq
context get it.
Thanks
Jianchao
>
> On 5/28/18, 6:11 PM, "jianchao.wang" wrote:
>
> Hi Himanshu
>
> do you need any other information ?
>
> Thanks
> Jianchao
>
> On 05/25/2018 02:48 PM, jianchao.wang wrote:
> > Hi Himanshu
> >
> > I'm afraid I cannot provide you the vmcore file, it is from our
> customer.
> > If any information needed in the vmcore, I could provide with you.
> >
> > In this scene, there are two contexts:
> > 1. the irq context, scsi_done() from qla2x00_sp_compl()
> > 2. the kworker context, scmd_eh_abort_handler which invokes the
> > qla2xxx_eh_abort()
> >
> > Let's see the irq context.
> > scsi_done() will invoke the blk_complete_request().
> > In common case, the REQ_ATOM_COMPLETE should have been set by
> > blk_rq_check_expired() when the request was confirmed timeout. So
> > __blk_complete_request() will not be invoked.
> >
> > On the other hand, in the kworker context, scmd_eh_abort_handler() will
> do some
> > other things on this aborted request.
> >
> > rtn = scsi_try_to_abort_cmd(sdev->host->hostt, scmd);
> > if (rtn == SUCCESS) {
> > set_host_byte(scmd, DID_TIME_OUT)
> > if (scsi_host_eh_past_deadline(sdev->host)) {
> >
> > } else if (!scsi_noretry_cmd(scmd) &&
> > (++scmd->retries <= scmd->allowed)) {
> > scsi_queue_insert(scmd, SCSI_MLQUEUE_EH_RETRY)
> > }
> >
> > }
> > The host type of the result will set to DID_TIME_OUT.
> scsi_noretry_cmd() will
> > return false and scsi_queue_insert() will be invoked, finally the
> > blk_requeue_request().
> >
> > blk_requeue_request() will clear the REQ_ATOM_COMPLETE and queue the
> request on
> > request_queue->queue_head.
> >
> > There could be a race between these two contexts:
> > what if the blk_clear_rq_complete() in kworker context is invoked
> before the
> > blk_mark_rq_complete() in irq context ?
> >
> > BLK_SOFTIRQ will be raised by __blk_complete_request() in irq context.
> Then the
> > scsi_softirq_done() will be invoked. At the moment, the request has been
> > requeued by kworker context and scsi_cmnd->result is set 0. On the cpu
> of the
> > irq context, the blk_finish_request() will be invoked finally, and
> panic comes
> > up due to BUG_ON(blk_queued_rq(req)
> >
> > Here is the dmesg log.
> > [4937745.180213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.180655] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181059] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.181514] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 0 2002.
> > [4937745.181636] [ cut here ]
> > [4937745.181900] kernel BUG at block/blk-core.c:2601!
> > [4937745.182095] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.182338] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183046] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.183213] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.183844] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:5:5 -- 1 2002.
> > [4937745.184038] qla2xxx [:92:00.1]-801c:4: Abort command issued
> nexus=4:4:73 -- 1 2002.
> > [4937745.184919] invalid opcode: [#1] SMP
> > [4937745.185173] Modules linked in: ...
> > [4937745.188237] CPU: 18 PID: 0 Comm: swapper/18 Not tainted
> 4.1.12-61.1.9.el6uek.x86_64 #2
> > [4937745.188691] Hardware name: Oracle Corporation SUN BLADE X4-2B
> /BD,ASSY,PCB,X4-2B , BIOS 28010200 01/16/2014
>
Re: [git pull] Input updates for v4.17-rc7
On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov wrote: > We are switching a bunch of > Lenovo devices with Synaptics touchpads from PS/2 emulation over to > native RMI/SMbus. > Given that all commits are marked for stable there is no point delaying > them till next release. Hmm. The elan driver stack overrun isn't mentioned, but seems more fundamental fix than the other changes that just add a few new PnP ID's... Linus
Re: [git pull] Input updates for v4.17-rc7
On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov wrote: > We are switching a bunch of > Lenovo devices with Synaptics touchpads from PS/2 emulation over to > native RMI/SMbus. > Given that all commits are marked for stable there is no point delaying > them till next release. Hmm. The elan driver stack overrun isn't mentioned, but seems more fundamental fix than the other changes that just add a few new PnP ID's... Linus
[PATCH] PCI: Add pci=safemode option
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case BIOS hands off a broken
configuration.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
drivers/pci/pci.c | 7 +++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/portdrv_core.c | 2 +-
drivers/pci/probe.c | 6 ++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 641ec9c..247adbb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3153,6 +3153,8 @@
noari do not use PCIe ARI.
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
+ safemodeturns of all optinal PCI features. Useful
+ for bringup/troubleshooting.
pcie_scan_all Scan all possible PCIe devices. Otherwise we
only look for one device below a PCIe downstream
port.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d27f771..11f0282 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, disables most of the optional PCI features */
+bool pci_safe_mode;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5845,6 +5848,10 @@ static int __init pci_setup(char *str)
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "safemode", 8)) {
+ pr_info("PCI: safe mode with minimum
features\n");
+ pci_safe_mode = true;
+ pcie_bus_config = PCIE_BUS_SAFE;
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..4517bcd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -8,6 +8,8 @@
extern const unsigned char pcie_link_speed[];
+extern bool pci_safe_mode;
+
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index a5b3b3a..9fe4ed6 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -311,7 +311,7 @@ int pcie_port_device_register(struct pci_dev *dev)
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
- if (!capabilities)
+ if (!capabilities || pci_safe_mode)
return 0;
pci_set_master(dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..295b79c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2047,6 +2047,9 @@ static void pci_configure_device(struct pci_dev *dev)
struct hotplug_params hpp;
int ret;
+ if (pci_safe_mode)
+ return;
+
pci_configure_mps(dev);
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
@@ -2213,6 +2216,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Setup MSI caps & disable MSI/MSI-X interrupts */
pci_msi_setup_pci_dev(dev);
+ if (pci_safe_mode)
+ return;
+
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
--
2.7.4
[PATCH] PCI: Add pci=safemode option
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case BIOS hands off a broken
configuration.
Signed-off-by: Sinan Kaya
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
drivers/pci/pci.c | 7 +++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/portdrv_core.c | 2 +-
drivers/pci/probe.c | 6 ++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 641ec9c..247adbb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3153,6 +3153,8 @@
noari do not use PCIe ARI.
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
+ safemodeturns of all optinal PCI features. Useful
+ for bringup/troubleshooting.
pcie_scan_all Scan all possible PCIe devices. Otherwise we
only look for one device below a PCIe downstream
port.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d27f771..11f0282 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, disables most of the optional PCI features */
+bool pci_safe_mode;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5845,6 +5848,10 @@ static int __init pci_setup(char *str)
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "safemode", 8)) {
+ pr_info("PCI: safe mode with minimum
features\n");
+ pci_safe_mode = true;
+ pcie_bus_config = PCIE_BUS_SAFE;
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..4517bcd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -8,6 +8,8 @@
extern const unsigned char pcie_link_speed[];
+extern bool pci_safe_mode;
+
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index a5b3b3a..9fe4ed6 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -311,7 +311,7 @@ int pcie_port_device_register(struct pci_dev *dev)
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
- if (!capabilities)
+ if (!capabilities || pci_safe_mode)
return 0;
pci_set_master(dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..295b79c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2047,6 +2047,9 @@ static void pci_configure_device(struct pci_dev *dev)
struct hotplug_params hpp;
int ret;
+ if (pci_safe_mode)
+ return;
+
pci_configure_mps(dev);
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
@@ -2213,6 +2216,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Setup MSI caps & disable MSI/MSI-X interrupts */
pci_msi_setup_pci_dev(dev);
+ if (pci_safe_mode)
+ return;
+
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
--
2.7.4
[PATCH 1/3] mfd: cros: add charger port count command definition
A new more command has been added to the ChromeOS embedded controller
that allows to get the number of charger port count. Unlike
EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
port if present.
This command will be used to expose the dedicated charger port
in the ChromeOS charger driver.
Signed-off-by: Fabien Parent
---
include/linux/mfd/cros_ec_commands.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 0d926492ac3a..e3187f8bdb7e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -3005,6 +3005,16 @@ struct ec_params_usb_pd_info_request {
uint8_t port;
} __packed;
+/*
+ * This command will return the number of USB PD charge port + the number
+ * of dedicated port present.
+ * EC_CMD_USB_PD_PORTS does NOT include the dedicated ports
+ */
+#define EC_CMD_CHARGE_PORT_COUNT 0x0105
+struct ec_response_charge_port_count {
+ uint8_t port_count;
+} __packed;
+
/* Read USB-PD Device discovery info */
#define EC_CMD_USB_PD_DISCOVERY 0x0113
struct ec_params_usb_pd_discovery_entry {
--
2.17.0
[PATCH 2/3] power: supply: cros: add support for dedicated port
ChromeOS devices can have one optional dedicated port.
The Dedicated port is unique and similar to the USB PD ports
except that it doesn't support as many properties.
The presence of a dedicated port is determined from whether the
EC's charger port count is equal to 'number of USB PD port' + 1.
The dedicated port ID is always the last valid port ID.
This commit keeps compatibility with Embedded Controllers that do not
support the new EC_CMD_CHARGE_PORT_COUNT command by setting
the number of charger port to be equal to the number of USB PD port
when this command fails.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 115 +++---
1 file changed, 101 insertions(+), 14 deletions(-)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 3a0c96fd1bc1..808688a6586c 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -12,8 +12,12 @@
#include
#include
-#define CHARGER_DIR_NAME "CROS_USBPD_CHARGER%d"
-#define CHARGER_DIR_NAME_LENGTHsizeof(CHARGER_DIR_NAME)
+#define CHARGER_USBPD_DIR_NAME "CROS_USBPD_CHARGER%d"
+#define CHARGER_DEDICATED_DIR_NAME "CROS_DEDICATED_CHARGER"
+#define CHARGER_DIR_NAME_LENGTH(sizeof(CHARGER_USBPD_DIR_NAME)
>= \
+sizeof(CHARGER_DEDICATED_DIR_NAME) ? \
+sizeof(CHARGER_USBPD_DIR_NAME) : \
+sizeof(CHARGER_DEDICATED_DIR_NAME))
#define CHARGER_CACHE_UPDATE_DELAY msecs_to_jiffies(500)
#define CHARGER_MANUFACTURER_MODEL_LENGTH 32
@@ -42,6 +46,7 @@ struct charger_data {
struct cros_ec_dev *ec_dev;
struct cros_ec_device *ec_device;
int num_charger_ports;
+ int num_usbpd_ports;
int num_registered_psy;
struct port_data *ports[EC_USB_PD_MAX_PORTS];
struct notifier_block notifier;
@@ -58,6 +63,12 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
POWER_SUPPLY_PROP_USB_TYPE
};
+static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+};
+
static enum power_supply_usb_type cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_UNKNOWN,
POWER_SUPPLY_USB_TYPE_SDP,
@@ -69,6 +80,11 @@ static enum power_supply_usb_type
cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID
};
+static bool cros_usbpd_charger_port_is_dedicated(struct port_data *port)
+{
+ return port->port_number >= port->charger->num_usbpd_ports;
+}
+
static int cros_usbpd_charger_ec_command(struct charger_data *charger,
unsigned int version,
unsigned int command,
@@ -102,6 +118,23 @@ static int cros_usbpd_charger_ec_command(struct
charger_data *charger,
}
static int cros_usbpd_charger_get_num_ports(struct charger_data *charger)
+{
+ struct ec_response_charge_port_count resp;
+ int ret;
+
+ ret = cros_usbpd_charger_ec_command(charger, 0,
+ EC_CMD_CHARGE_PORT_COUNT,
+ NULL, 0, , sizeof(resp));
+ if (ret < 0) {
+ dev_err(charger->dev,
+ "Unable to get the number of ports (err:0x%x)\n", ret);
+ return ret;
+ }
+
+ return resp.port_count;
+}
+
+static int cros_usbpd_charger_get_usbpd_num_ports(struct charger_data *charger)
{
struct ec_response_usb_pd_ports resp;
int ret;
@@ -246,7 +279,10 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
port->psy_usb_type = POWER_SUPPLY_USB_TYPE_SDP;
}
- port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
+ if (cros_usbpd_charger_port_is_dedicated(port))
+ port->psy_desc.type = POWER_SUPPLY_TYPE_MAINS;
+ else
+ port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
dev_dbg(dev,
"Port %d: type=%d vmax=%d vnow=%d cmax=%d clim=%d pmax=%d\n",
@@ -281,7 +317,8 @@ static int cros_usbpd_charger_get_port_status(struct
port_data *port,
if (ret < 0)
return ret;
- ret = cros_usbpd_charger_get_discovery_info(port);
+ if (!cros_usbpd_charger_port_is_dedicated(port))
+ ret = cros_usbpd_charger_get_discovery_info(port);
port->last_update = jiffies;
return ret;
@@ -425,17 +462,56 @@ static int cros_usbpd_charger_probe(struct
platform_device *pd)
platform_set_drvdata(pd, charger);
+ /*
+* We need to know the number of USB PD ports in order to know whether
+* there is a dedicated port. The dedicated port will
[PATCH 1/3] mfd: cros: add charger port count command definition
A new more command has been added to the ChromeOS embedded controller
that allows to get the number of charger port count. Unlike
EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
port if present.
This command will be used to expose the dedicated charger port
in the ChromeOS charger driver.
Signed-off-by: Fabien Parent
---
include/linux/mfd/cros_ec_commands.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 0d926492ac3a..e3187f8bdb7e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -3005,6 +3005,16 @@ struct ec_params_usb_pd_info_request {
uint8_t port;
} __packed;
+/*
+ * This command will return the number of USB PD charge port + the number
+ * of dedicated port present.
+ * EC_CMD_USB_PD_PORTS does NOT include the dedicated ports
+ */
+#define EC_CMD_CHARGE_PORT_COUNT 0x0105
+struct ec_response_charge_port_count {
+ uint8_t port_count;
+} __packed;
+
/* Read USB-PD Device discovery info */
#define EC_CMD_USB_PD_DISCOVERY 0x0113
struct ec_params_usb_pd_discovery_entry {
--
2.17.0
[PATCH 2/3] power: supply: cros: add support for dedicated port
ChromeOS devices can have one optional dedicated port.
The Dedicated port is unique and similar to the USB PD ports
except that it doesn't support as many properties.
The presence of a dedicated port is determined from whether the
EC's charger port count is equal to 'number of USB PD port' + 1.
The dedicated port ID is always the last valid port ID.
This commit keeps compatibility with Embedded Controllers that do not
support the new EC_CMD_CHARGE_PORT_COUNT command by setting
the number of charger port to be equal to the number of USB PD port
when this command fails.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 115 +++---
1 file changed, 101 insertions(+), 14 deletions(-)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 3a0c96fd1bc1..808688a6586c 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -12,8 +12,12 @@
#include
#include
-#define CHARGER_DIR_NAME "CROS_USBPD_CHARGER%d"
-#define CHARGER_DIR_NAME_LENGTHsizeof(CHARGER_DIR_NAME)
+#define CHARGER_USBPD_DIR_NAME "CROS_USBPD_CHARGER%d"
+#define CHARGER_DEDICATED_DIR_NAME "CROS_DEDICATED_CHARGER"
+#define CHARGER_DIR_NAME_LENGTH(sizeof(CHARGER_USBPD_DIR_NAME)
>= \
+sizeof(CHARGER_DEDICATED_DIR_NAME) ? \
+sizeof(CHARGER_USBPD_DIR_NAME) : \
+sizeof(CHARGER_DEDICATED_DIR_NAME))
#define CHARGER_CACHE_UPDATE_DELAY msecs_to_jiffies(500)
#define CHARGER_MANUFACTURER_MODEL_LENGTH 32
@@ -42,6 +46,7 @@ struct charger_data {
struct cros_ec_dev *ec_dev;
struct cros_ec_device *ec_device;
int num_charger_ports;
+ int num_usbpd_ports;
int num_registered_psy;
struct port_data *ports[EC_USB_PD_MAX_PORTS];
struct notifier_block notifier;
@@ -58,6 +63,12 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
POWER_SUPPLY_PROP_USB_TYPE
};
+static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+};
+
static enum power_supply_usb_type cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_UNKNOWN,
POWER_SUPPLY_USB_TYPE_SDP,
@@ -69,6 +80,11 @@ static enum power_supply_usb_type
cros_usbpd_charger_usb_types[] = {
POWER_SUPPLY_USB_TYPE_APPLE_BRICK_ID
};
+static bool cros_usbpd_charger_port_is_dedicated(struct port_data *port)
+{
+ return port->port_number >= port->charger->num_usbpd_ports;
+}
+
static int cros_usbpd_charger_ec_command(struct charger_data *charger,
unsigned int version,
unsigned int command,
@@ -102,6 +118,23 @@ static int cros_usbpd_charger_ec_command(struct
charger_data *charger,
}
static int cros_usbpd_charger_get_num_ports(struct charger_data *charger)
+{
+ struct ec_response_charge_port_count resp;
+ int ret;
+
+ ret = cros_usbpd_charger_ec_command(charger, 0,
+ EC_CMD_CHARGE_PORT_COUNT,
+ NULL, 0, , sizeof(resp));
+ if (ret < 0) {
+ dev_err(charger->dev,
+ "Unable to get the number of ports (err:0x%x)\n", ret);
+ return ret;
+ }
+
+ return resp.port_count;
+}
+
+static int cros_usbpd_charger_get_usbpd_num_ports(struct charger_data *charger)
{
struct ec_response_usb_pd_ports resp;
int ret;
@@ -246,7 +279,10 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
port->psy_usb_type = POWER_SUPPLY_USB_TYPE_SDP;
}
- port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
+ if (cros_usbpd_charger_port_is_dedicated(port))
+ port->psy_desc.type = POWER_SUPPLY_TYPE_MAINS;
+ else
+ port->psy_desc.type = POWER_SUPPLY_TYPE_USB;
dev_dbg(dev,
"Port %d: type=%d vmax=%d vnow=%d cmax=%d clim=%d pmax=%d\n",
@@ -281,7 +317,8 @@ static int cros_usbpd_charger_get_port_status(struct
port_data *port,
if (ret < 0)
return ret;
- ret = cros_usbpd_charger_get_discovery_info(port);
+ if (!cros_usbpd_charger_port_is_dedicated(port))
+ ret = cros_usbpd_charger_get_discovery_info(port);
port->last_update = jiffies;
return ret;
@@ -425,17 +462,56 @@ static int cros_usbpd_charger_probe(struct
platform_device *pd)
platform_set_drvdata(pd, charger);
+ /*
+* We need to know the number of USB PD ports in order to know whether
+* there is a dedicated port. The dedicated port will
Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
On Wed, 30 May 2018 01:41:43 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > Jacob Pan wrote: > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > Jean-Philippe Brucker wrote: > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > [...] > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > aligned or the format of the PASID table? Are these all > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > maybe we could note that and the spec which defines them when we > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > understand how we'll match a user provided PASID table to the > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > guest > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > Maybe this information could be part of the data passed to userspace > > > > about IOMMU table formats and features? They're not part of this > > > > series, but I think we wanted to communicate IOMMU-specific features > > > > via sysfs. > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > can match IOMMU model and features. > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > interface. Are we suggesting that the /only/ way to make use of the > > internal IOMMU API here is to have a user provided opaque pasid table > > that we can't even do minimal compatibility sanity testing on and we > > simply hope that hardware covers all the fault conditions without > > taking the host down with it? I guess we have to assume the latter > > since the user has full control of the table, but I have a hard time > > getting past lack of internal ability to use the interface and no > > ability to provide even the slimmest sanity testing. Thanks, > > > > checking size, alignment, ... is OK, which I think is already considered > by vendor IOMMU driver. However sanity testing table format might > be difficult. The initial table provided by guest is likely just all ZEROs. > whatever format violation may be caught only when a PASID entry > is updated... There's sanity testing the actual contents of the table, which I agree would be difficult and would likely require some sort of shadowing at additional overhead, but what about even basic consistency checking? For example, is it possible that due to hardware variations a user might generate a table which works on some systems but not others? What if two table formats are sufficiently similar that the IOMMU driver puts an incompatible table in place but it continuously generates faults, how do we debug that? As an intermediary in this whole process I'd really rather be able to identify that the user claims to be providing a TypeA table but the IOMMU only supports TypeB, so clearly this won't work. I don't see that we have that capability. Thanks, Alex
[PATCH 3/3] power: supply: cros: add property to detect connected ports
When a port is connected but acting as a source, its 'online' and
'status' properties are identical to a port that is not connected. This
makes it tedious for userspace to know for sure whether a port is
connected or not.
This commit adds a new property 'present' to reflect whether a port
is connected or not.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 808688a6586c..d44ab35670ab 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -32,6 +32,7 @@ struct port_data {
struct power_supply_desc psy_desc;
int psy_usb_type;
int psy_online;
+ int psy_present;
int psy_status;
int psy_current_max;
int psy_voltage_max_design;
@@ -54,6 +55,7 @@ struct charger_data {
static enum power_supply_property cros_usbpd_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
@@ -65,6 +67,7 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
@@ -205,18 +208,22 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
case USB_PD_PORT_POWER_DISCONNECTED:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 0;
break;
case USB_PD_PORT_POWER_SOURCE:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK:
port->psy_status = POWER_SUPPLY_STATUS_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK_NOT_CHARGING:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
default:
dev_err(dev, "Unknown role %d\n", resp.role);
@@ -362,6 +369,7 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
*/
if (ec_device->mkbp_event_supported || port->psy_online)
break;
+ case POWER_SUPPLY_PROP_PRESENT:
case POWER_SUPPLY_PROP_CURRENT_MAX:
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -380,6 +388,9 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
case POWER_SUPPLY_PROP_ONLINE:
val->intval = port->psy_online;
break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = port->psy_present;
+ break;
case POWER_SUPPLY_PROP_STATUS:
val->intval = port->psy_status;
break;
--
2.17.0
Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function
On Wed, 30 May 2018 01:41:43 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, May 30, 2018 4:09 AM > > > > On Fri, 20 Apr 2018 16:42:51 -0700 > > Jacob Pan wrote: > > > > > On Fri, 20 Apr 2018 19:25:34 +0100 > > > Jean-Philippe Brucker wrote: > > > > > > > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > > > > [...] > > > > > > + /* Assign guest PASID table pointer and size order */ > > > > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > > > > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > > > > > > > > > Where does this IOMMU API interface define that base_ptr is 4K > > > > > aligned or the format of the PASID table? Are these all > > > > > standardized or do they vary by host IOMMU? If they're standards, > > > > > maybe we could note that and the spec which defines them when we > > > > > declare base_ptr. If they're IOMMU specific then I don't > > > > > understand how we'll match a user provided PASID table to the > > > > > requirements and format of the host IOMMU. Thanks, > > > > > > > > On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a > > guest > > > > under a vSMMU might pass a pointer that's not aligned on 4k. > > > > > > > PASID table pointer for VT-d is 4K aligned. > > > > Maybe this information could be part of the data passed to userspace > > > > about IOMMU table formats and features? They're not part of this > > > > series, but I think we wanted to communicate IOMMU-specific features > > > > via sysfs. > > > > > > > Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU > > > can match IOMMU model and features. > > > > Digging this up again since v5 still has this issue. The IOMMU API is > > a kernel internal abstraction of the IOMMU. sysfs is a userspace > > interface. Are we suggesting that the /only/ way to make use of the > > internal IOMMU API here is to have a user provided opaque pasid table > > that we can't even do minimal compatibility sanity testing on and we > > simply hope that hardware covers all the fault conditions without > > taking the host down with it? I guess we have to assume the latter > > since the user has full control of the table, but I have a hard time > > getting past lack of internal ability to use the interface and no > > ability to provide even the slimmest sanity testing. Thanks, > > > > checking size, alignment, ... is OK, which I think is already considered > by vendor IOMMU driver. However sanity testing table format might > be difficult. The initial table provided by guest is likely just all ZEROs. > whatever format violation may be caught only when a PASID entry > is updated... There's sanity testing the actual contents of the table, which I agree would be difficult and would likely require some sort of shadowing at additional overhead, but what about even basic consistency checking? For example, is it possible that due to hardware variations a user might generate a table which works on some systems but not others? What if two table formats are sufficiently similar that the IOMMU driver puts an incompatible table in place but it continuously generates faults, how do we debug that? As an intermediary in this whole process I'd really rather be able to identify that the user claims to be providing a TypeA table but the IOMMU only supports TypeB, so clearly this won't work. I don't see that we have that capability. Thanks, Alex
[PATCH 3/3] power: supply: cros: add property to detect connected ports
When a port is connected but acting as a source, its 'online' and
'status' properties are identical to a port that is not connected. This
makes it tedious for userspace to know for sure whether a port is
connected or not.
This commit adds a new property 'present' to reflect whether a port
is connected or not.
Signed-off-by: Fabien Parent
---
drivers/power/supply/cros_usbpd-charger.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/power/supply/cros_usbpd-charger.c
b/drivers/power/supply/cros_usbpd-charger.c
index 808688a6586c..d44ab35670ab 100644
--- a/drivers/power/supply/cros_usbpd-charger.c
+++ b/drivers/power/supply/cros_usbpd-charger.c
@@ -32,6 +32,7 @@ struct port_data {
struct power_supply_desc psy_desc;
int psy_usb_type;
int psy_online;
+ int psy_present;
int psy_status;
int psy_current_max;
int psy_voltage_max_design;
@@ -54,6 +55,7 @@ struct charger_data {
static enum power_supply_property cros_usbpd_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
@@ -65,6 +67,7 @@ static enum power_supply_property cros_usbpd_charger_props[]
= {
static enum power_supply_property cros_usbpd_dedicated_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
@@ -205,18 +208,22 @@ static int cros_usbpd_charger_get_power_info(struct
port_data *port)
case USB_PD_PORT_POWER_DISCONNECTED:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 0;
break;
case USB_PD_PORT_POWER_SOURCE:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 0;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK:
port->psy_status = POWER_SUPPLY_STATUS_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
case USB_PD_PORT_POWER_SINK_NOT_CHARGING:
port->psy_status = POWER_SUPPLY_STATUS_NOT_CHARGING;
port->psy_online = 1;
+ port->psy_present = 1;
break;
default:
dev_err(dev, "Unknown role %d\n", resp.role);
@@ -362,6 +369,7 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
*/
if (ec_device->mkbp_event_supported || port->psy_online)
break;
+ case POWER_SUPPLY_PROP_PRESENT:
case POWER_SUPPLY_PROP_CURRENT_MAX:
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -380,6 +388,9 @@ static int cros_usbpd_charger_get_prop(struct power_supply
*psy,
case POWER_SUPPLY_PROP_ONLINE:
val->intval = port->psy_online;
break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = port->psy_present;
+ break;
case POWER_SUPPLY_PROP_STATUS:
val->intval = port->psy_status;
break;
--
2.17.0
