Re: [PATCH 0/2] docs/mm-api: link kernel-doc comments from slab_common.c
ping?
On Thu, Dec 06, 2018 at 11:12:59PM +0200, Mike Rapoport wrote:
> Hi,
>
> These patches update formatting of function descriptions in
> mm/slab_common.c and link the comments from this file to "The Slab Cache"
> section of the MM API reference.
>
> As the changes to mm/slab_common.c only touch the comments, I think these
> patches can go via the docs tree.
>
> Mike Rapoport (2):
> slab: make kmem_cache_create{_usercopy} description proper kernel-doc
> docs/mm-api: link slab_common.c to "The Slab Cache" section
>
> Documentation/core-api/mm-api.rst | 3 +++
> mm/slab_common.c | 35 +++
> 2 files changed, 34 insertions(+), 4 deletions(-)
>
> --
> 2.7.4
>
--
Sincerely yours,
Mike.
[PATCH] rts5208: add a missing check for the status of command sending
ms_send_cmd() may fail. The fix checks the return value of it, and if it
fails, returns the error "STATUS_FAIL" upstream.
Signed-off-by: Kangjie Lu
---
drivers/staging/rts5208/ms.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index f53adf15c685..5a9e562465e9 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -2731,7 +2731,9 @@ static int mspro_rw_multi_sector(struct scsi_cmnd *srb,
}
if (val & MS_INT_BREQ)
- ms_send_cmd(chip, PRO_STOP, WAIT_INT);
+ retval = ms_send_cmd(chip, PRO_STOP, WAIT_INT);
+ if (retval != STATUS_SUCCESS)
+ return STATUS_FAIL;
if (val & (MS_CRC16_ERR | MS_RDY_TIMEOUT)) {
dev_dbg(rtsx_dev(chip), "MSPro CRC error, tune
clock!\n");
--
2.17.2 (Apple Git-113)
[PATCH 2/3] sched/fair: trigger asym_packing during idle load balance
newly idle load balance is not always triggered when a cpu becomes idle.
This prevent the scheduler to get a chance to migrate task for asym packing.
Enable active migration because of asym packing during idle load balance too.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9b31247..487c73e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8853,7 +8853,7 @@ static int need_active_balance(struct lb_env *env)
{
struct sched_domain *sd = env->sd;
- if (env->idle == CPU_NEWLY_IDLE) {
+ if (env->idle != CPU_NOT_IDLE) {
/*
* ASYM_PACKING needs to force migrate tasks from busy but
--
2.7.4
[PATCH 3/3] sched/fair: fix unnecessary increase of balance interval
In case of active balance, we increase the balance interval to cover
pinned tasks cases not covered by all_pinned logic. Neverthless, the
active migration triggered by asym packing should be treated as the normal
unbalanced case and reset the interval to default value otherwise active
migration for asym_packing can be easily delayed for hundreds of ms
because of this pinned task detection mecanism.
The same happen to other conditions tested in need_active_balance() like
mistfit task and when the capacity of src_cpu is reduced compared to
dst_cpu (see comments in need_active_balance() for details).
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 487c73e..9b1e701 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8849,21 +8849,25 @@ static struct rq *find_busiest_queue(struct lb_env *env,
*/
#define MAX_PINNED_INTERVAL512
-static int need_active_balance(struct lb_env *env)
+static inline bool
+asym_active_balance(struct lb_env *env)
{
- struct sched_domain *sd = env->sd;
+ /*
+* ASYM_PACKING needs to force migrate tasks from busy but
+* lower priority CPUs in order to pack all tasks in the
+* highest priority CPUs.
+*/
+ return env->idle != CPU_NOT_IDLE && (env->sd->flags & SD_ASYM_PACKING)
&&
+ sched_asym_prefer(env->dst_cpu, env->src_cpu);
+}
- if (env->idle != CPU_NOT_IDLE) {
+static inline bool
+voluntary_active_balance(struct lb_env *env)
+{
+ struct sched_domain *sd = env->sd;
- /*
-* ASYM_PACKING needs to force migrate tasks from busy but
-* lower priority CPUs in order to pack all tasks in the
-* highest priority CPUs.
-*/
- if ((sd->flags & SD_ASYM_PACKING) &&
- sched_asym_prefer(env->dst_cpu, env->src_cpu))
- return 1;
- }
+ if (asym_active_balance(env))
+ return 1;
/*
* The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
@@ -8881,6 +8885,16 @@ static int need_active_balance(struct lb_env *env)
if (env->src_grp_type == group_misfit_task)
return 1;
+ return 0;
+}
+
+static int need_active_balance(struct lb_env *env)
+{
+ struct sched_domain *sd = env->sd;
+
+ if (voluntary_active_balance(env))
+ return 1;
+
return unlikely(sd->nr_balance_failed > sd->cache_nice_tries+2);
}
@@ -9142,7 +9156,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
} else
sd->nr_balance_failed = 0;
- if (likely(!active_balance)) {
+ if (likely(!active_balance) || voluntary_active_balance()) {
/* We were unbalanced, so reset the balancing interval */
sd->balance_interval = sd->min_interval;
} else {
--
2.7.4
[PATCH v3 1/3] sched/fair: fix rounding issue for asym packing
When check_asym_packing() is triggered, the imbalance is set to : busiest_stat.avg_load * busiest_stat.group_capacity / SCHED_CAPACITY_SCALE But busiest_stat.avg_load equals sgs->group_load *SCHED_CAPACITY_SCALE / sgs->group_capacity These divisions can generate a rounding that will make imbalance slightly lower than the weighted load of the cfs_rq. But this is enough to skip the rq in find_busiest_queue and prevents asym migration to happen. Directly set imbalance to sgs->group_load to remove the rounding. Signed-off-by: Vincent Guittot --- kernel/sched/fair.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ca46964..9b31247 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8476,9 +8476,7 @@ static int check_asym_packing(struct lb_env *env, struct sd_lb_stats *sds) if (sched_asym_prefer(busiest_cpu, env->dst_cpu)) return 0; - env->imbalance = DIV_ROUND_CLOSEST( - sds->busiest_stat.avg_load * sds->busiest_stat.group_capacity, - SCHED_CAPACITY_SCALE); + env->imbalance = sds->busiest_stat.avg_load; return 1; } -- 2.7.4
Re: [PATCH v5 01/15] KVM: s390: unregister debug feature on failing arch init
On 20.12.2018 08:49, Michael Mueller wrote: > > > On 19.12.18 21:10, Cornelia Huck wrote: >> On Wed, 19 Dec 2018 20:17:42 +0100 >> Michael Mueller wrote: >> >>> Make sure the debug feature and its allocated resources get >>> released upon unsuccessful architecture initialization. >>> >>> A related indication of the issue will be reported as kernel >>> message. >>> >>> Signed-off-by: Michael Mueller >>> Reviewed-by: Cornelia Huck >>> Reviewed-by: Pierre Morel >>> Reviewed-by: David Hildenbrand >>> Message-Id: <20181130143215.69496-2-m...@linux.ibm.com> >>> Signed-off-by: Christian Borntraeger >>> --- >>> Documentation/kmsg/s390/kvm | 12 >>> arch/s390/kvm/kvm-s390.c | 17 ++--- >>> 2 files changed, 26 insertions(+), 3 deletions(-) >>> create mode 100644 Documentation/kmsg/s390/kvm >>> >>> diff --git a/Documentation/kmsg/s390/kvm b/Documentation/kmsg/s390/kvm >>> new file mode 100644 >>> index ..76ffe2012254 >>> --- /dev/null >>> +++ b/Documentation/kmsg/s390/kvm >>> @@ -0,0 +1,12 @@ >>> +/*? >>> + * Text: "Failed to register FLIC rc=%d\n" >>> + * Severity: Error >>> + * Parameter: >>> + * @1: return code of the FLIC registration call >>> + * Description: >>> + * The registration of the FLIC (Floating Interrupt Controller Interface) >>> + * was not successful. >>> + * User action: >>> + * If this problem persists after a reload of the kvm kernel module, gather >>> + * Linux debug data and contact your support organization. >>> + */ >> >> Hm, it seems that the kmsg stuff crept in there again... >> > > picked from wrong branch, sorry... > FWIW, this patch without kmsg one is now part of kvm/next. https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=next=308c3e6673b012beecb96ef04cc65f4a0e7cdd99
[PATCH v3 0/3] sched/fair: some fixes for asym_packing
During the review of misfit task patchset, Morten and Valentin raised some problems with the use of SD_ASYM_PACKING flag on asymmetric system like hikey960 arm64 big/LITTLE platform. The study of the use cases has shown some problems that can happen for every systems that use the flag. The 3 patches fixes the problems raised for lmbench and the rt-app UC that creates 2 tasks that start as small tasks and then become suddenly always running tasks. (I can provide the rt-app json if needed) Changes since v2: - include other active balance reasons - set imbalance to avg_load as suggested by Valentin Changes since v1: - rebase on tip/sched/core - changes asym_active_balance() as suggested by Peter Vincent Guittot (3): sched/fair: fix rounding issue for asym packing sched/fair: trigger asym_packing during idle load balance sched/fair: fix unnecessary increase of balance interval kernel/sched/fair.c | 44 1 file changed, 28 insertions(+), 16 deletions(-) -- 2.7.4
Re: [RESEND PATCH v2] megaraid: fix out-of-bound array accesses
On Thu, Dec 13, 2018 at 6:57 PM Qian Cai wrote:
>
> UBSAN reported those with MegaRAID SAS-3 3108,
>
> [ 77.467308] UBSAN: Undefined behaviour in
> drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
> [ 77.475402] index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
> [ 77.481677] CPU: 16 PID: 333 Comm: kworker/16:1 Not tainted 4.20.0-rc5+ #1
> [ 77.488556] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> 06/01/2018
> [ 77.495791] Workqueue: events work_for_cpu_fn
> [ 77.500154] Call trace:
> [ 77.502610] dump_backtrace+0x0/0x2c8
> [ 77.506279] show_stack+0x24/0x30
> [ 77.509604] dump_stack+0x118/0x19c
> [ 77.513098] ubsan_epilogue+0x14/0x60
> [ 77.516765] __ubsan_handle_out_of_bounds+0xfc/0x13c
> [ 77.521767] mr_update_load_balance_params+0x150/0x158 [megaraid_sas]
> [ 77.528230] MR_ValidateMapInfo+0x2cc/0x10d0 [megaraid_sas]
> [ 77.533825] megasas_get_map_info+0x244/0x2f0 [megaraid_sas]
> [ 77.539505] megasas_init_adapter_fusion+0x9b0/0xf48 [megaraid_sas]
> [ 77.545794] megasas_init_fw+0x1ab4/0x3518 [megaraid_sas]
> [ 77.551212] megasas_probe_one+0x2c4/0xbe0 [megaraid_sas]
> [ 77.556614] local_pci_probe+0x7c/0xf0
> [ 77.560365] work_for_cpu_fn+0x34/0x50
> [ 77.564118] process_one_work+0x61c/0xf08
> [ 77.568129] worker_thread+0x534/0xa70
> [ 77.571882] kthread+0x1c8/0x1d0
> [ 77.575114] ret_from_fork+0x10/0x1c
>
> [ 89.240332] UBSAN: Undefined behaviour in
> drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
> [ 89.248426] index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
> [ 89.254700] CPU: 16 PID: 95 Comm: kworker/u130:0 Not tainted 4.20.0-rc5+ #1
> [ 89.261665] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> 06/01/2018
> [ 89.268903] Workqueue: events_unbound async_run_entry_fn
> [ 89.274222] Call trace:
> [ 89.276680] dump_backtrace+0x0/0x2c8
> [ 89.280348] show_stack+0x24/0x30
> [ 89.283671] dump_stack+0x118/0x19c
> [ 89.287167] ubsan_epilogue+0x14/0x60
> [ 89.290835] __ubsan_handle_out_of_bounds+0xfc/0x13c
> [ 89.295828] MR_LdRaidGet+0x50/0x58 [megaraid_sas]
> [ 89.300638] megasas_build_io_fusion+0xbb8/0xd90 [megaraid_sas]
> [ 89.306576] megasas_build_and_issue_cmd_fusion+0x138/0x460 [megaraid_sas]
> [ 89.313468] megasas_queue_command+0x398/0x3d0 [megaraid_sas]
> [ 89.319222] scsi_dispatch_cmd+0x1dc/0x8a8
> [ 89.323321] scsi_request_fn+0x8e8/0xdd0
> [ 89.327249] __blk_run_queue+0xc4/0x158
> [ 89.331090] blk_execute_rq_nowait+0xf4/0x158
> [ 89.335449] blk_execute_rq+0xdc/0x158
> [ 89.339202] __scsi_execute+0x130/0x258
> [ 89.343041] scsi_probe_and_add_lun+0x2fc/0x1488
> [ 89.347661] __scsi_scan_target+0x1cc/0x8c8
> [ 89.351848] scsi_scan_channel.part.3+0x8c/0xc0
> [ 89.356382] scsi_scan_host_selected+0x130/0x1f0
> [ 89.361002] do_scsi_scan_host+0xd8/0xf0
> [ 89.364927] do_scan_async+0x9c/0x320
> [ 89.368594] async_run_entry_fn+0x138/0x420
> [ 89.372780] process_one_work+0x61c/0xf08
> [ 89.376793] worker_thread+0x13c/0xa70
> [ 89.380546] kthread+0x1c8/0x1d0
> [ 89.383778] ret_from_fork+0x10/0x1c
>
> This is because when populating Driver Map using firmware raid map, all
> non-existing VDs set their ldTgtIdToLd to 0xff, so it can be skipped
> later.
>
> From drivers/scsi/megaraid/megaraid_sas_base.c ,
> memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
>
> From drivers/scsi/megaraid/megaraid_sas_fp.c ,
> /* For non existing VDs, iterate to next VD*/
> if (ld >= (MAX_LOGICAL_DRIVES_EXT - 1))
> continue;
>
> However, there are a few places that failed to skip those non-existing
> VDs due to off-by-one errors. Then, those 0xff leaked into
> MR_LdRaidGet(0xff, map) and triggered the out-of-bound accesses.
>
> Fixes: 51087a8617fe (megaraid_sas : Extended VD support)
> Signed-off-by: Qian Cai
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +-
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
> b/drivers/scsi/megaraid/megaraid_sas_fp.c
> index 59ecbb3b53b5..a33628550425 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fp.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
> @@ -1266,7 +1266,7 @@ void mr_update_load_balance_params(struct
> MR_DRV_RAID_MAP_ALL *drv_map,
>
> for (ldCount = 0; ldCount < MAX_LOGICAL_DRIVES_EXT; ldCount++) {
> ld = MR_TargetIdToLdGet(ldCount, drv_map);
> - if (ld >= MAX_LOGICAL_DRIVES_EXT) {
> + if (ld >= MAX_LOGICAL_DRIVES_EXT - 1) {
> lbInfo[ldCount].loadBalanceFlag = 0;
> continue;
> }
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index f74b5ea24f0f..49eaa87608f6 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++
Re: [PATCH v2] dt-bindings: PCI: rcar: Add device tree support for r8a774c0
On Tue, Dec 18, 2018 at 12:02:42PM +, Fabrizio Castro wrote: > Add PCIe support for the RZ/G2E (a.k.a. R8A774C0). > > Signed-off-by: Fabrizio Castro > Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman
Re: [PATCH v5 01/15] KVM: s390: unregister debug feature on failing arch init
On 19.12.18 21:10, Cornelia Huck wrote: On Wed, 19 Dec 2018 20:17:42 +0100 Michael Mueller wrote: Make sure the debug feature and its allocated resources get released upon unsuccessful architecture initialization. A related indication of the issue will be reported as kernel message. Signed-off-by: Michael Mueller Reviewed-by: Cornelia Huck Reviewed-by: Pierre Morel Reviewed-by: David Hildenbrand Message-Id: <20181130143215.69496-2-m...@linux.ibm.com> Signed-off-by: Christian Borntraeger --- Documentation/kmsg/s390/kvm | 12 arch/s390/kvm/kvm-s390.c| 17 ++--- 2 files changed, 26 insertions(+), 3 deletions(-) create mode 100644 Documentation/kmsg/s390/kvm diff --git a/Documentation/kmsg/s390/kvm b/Documentation/kmsg/s390/kvm new file mode 100644 index ..76ffe2012254 --- /dev/null +++ b/Documentation/kmsg/s390/kvm @@ -0,0 +1,12 @@ +/*? + * Text: "Failed to register FLIC rc=%d\n" + * Severity: Error + * Parameter: + * @1: return code of the FLIC registration call + * Description: + * The registration of the FLIC (Floating Interrupt Controller Interface) + * was not successful. + * User action: + * If this problem persists after a reload of the kvm kernel module, gather + * Linux debug data and contact your support organization. + */ Hm, it seems that the kmsg stuff crept in there again... picked from wrong branch, sorry...
[PATCH] media: lgdt3306a: fix a missing check of return value
If lgdt3306a_read_reg() fails, the read data in "val" is incorrect, thus shouldn't be further used. The fix inserts a check for the return value of lgdt3306a_read_reg(). If it fails, goto fail. Signed-off-by: Kangjie Lu --- drivers/media/dvb-frontends/lgdt3306a.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/lgdt3306a.c b/drivers/media/dvb-frontends/lgdt3306a.c index 0e1f5daaf20c..7410f23314bc 100644 --- a/drivers/media/dvb-frontends/lgdt3306a.c +++ b/drivers/media/dvb-frontends/lgdt3306a.c @@ -1685,7 +1685,9 @@ static int lgdt3306a_read_signal_strength(struct dvb_frontend *fe, case QAM_256: case QAM_AUTO: /* need to know actual modulation to set proper SNR baseline */ - lgdt3306a_read_reg(state, 0x00a6, ); + ret = lgdt3306a_read_reg(state, 0x00a6, ); + if (lg_chkerr(ret)) + goto fail; if(val & 0x04) ref_snr = 2800; /* QAM-256 28dB */ else -- 2.17.2 (Apple Git-113)
Re: [PATCH net-next 0/9] net: hns3: code optimizations & bugfixes for HNS3 driver
From: Peng Li Date: Thu, 20 Dec 2018 11:51:57 +0800 > This patchset includes bugfixes and code optimizations for the HNS3 > ethernet controller driver Series applied, thanks.
[PATCH v3] arm64: dts: sdm845: add video nodes
This adds video nodes to sdm845 based on the examples
in the bindings.
Signed-off-by: Malathi Gottam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0..ccd2b10 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -87,6 +87,11 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+
+ venus_region: memory@9580 {
+ reg = <0x0 0x9580 0x0 0x50>;
+ no-map;
+ };
};
cpus {
@@ -1403,5 +1408,35 @@
status = "disabled";
};
};
+
+ video-codec@aa0 {
+ compatible = "qcom,sdm845-venus";
+ reg = <0x0aa0 0xff000>;
+ interrupts = ;
+ power-domains = < VENUS_GDSC>;
+ clocks = < VIDEO_CC_VENUS_CTL_CORE_CLK>,
+< VIDEO_CC_VENUS_AHB_CLK>,
+< VIDEO_CC_VENUS_CTL_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ iommus = <_smmu 0x10a0 0x8>,
+<_smmu 0x10b0 0x0>;
+ memory-region = <_region>;
+
+ video-core0 {
+ compatible = "venus-decoder";
+ clocks = < VIDEO_CC_VCODEC0_CORE_CLK>,
+< VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = < VCODEC0_GDSC>;
+ };
+
+ video-core1 {
+ compatible = "venus-encoder";
+ clocks = < VIDEO_CC_VCODEC1_CORE_CLK>,
+< VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = < VCODEC1_GDSC>;
+ };
+ };
};
};
--
1.9.1
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
Folks, I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. Maybe someone has a quick idea. [85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318 [85109.572036] Modules linked in: vhost_net vhost macvtap macvlan tap vfio_ap vfio_mdev mdev vfio_iommu_type1 vfio kvm xt_CHECKSUM ipt_MASQUERADE tun bridge stp llc xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nfnetlink ip6table_filter ip6_tables iptable_filter dm_service_time rpcrdma sunrpc rdma_ucm rdma_cm configfs iw_cm ib_cm mlx4_ib ib_uverbs ib_core pkey ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha1_s390 zcrypt_cex4 zcrypt rng_core eadm_sch sch_fq_codel ip_tables x_tables mlx4_en mlx4_core sha256_s390 sha_common dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_mirror dm_region_hash dm_log dm_mod autofs4 [85109.572072] CPU: 30 PID: 197360 Comm: vhost-197330 Not tainted 4.20.0-20181213.rc6.git0.407d079170c1.300.fc29.s390x #1 [85109.572074] Hardware name: IBM 2964 NC9 712 (LPAR) [85109.572075] Krnl PSW : 0704c0018000 0092e320 (__skb_flow_dissect+0x1f0/0x1318) [85109.572078]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [85109.572080] Krnl GPRS: 002a 03e0385bfc84 00d91e30 [85109.572081]03e0385bfc84 00d91e30 [85109.572083]03e0385bfc84 000e 007e3eb88100 007ff3561e00 [85109.572084]0806 00b4f288 03e0385bfbb8 03e0385bfab0 [85109.572115] Krnl Code: 0092e312: e310b0180002ltg %r1,24(%r11) 0092e318: a7740271brc 7,92e7fa #0092e31c: a7f40001brc 15,92e31e >0092e320: 91407003tm 3(%r7),64 0092e324: a7740257brc 7,92e7d2 0092e328: 5810f0b4l %r1,180(%r15) 0092e32c: e54cf0c8mvhi 200(%r15),0 0092e332: c01b0008nilf%r1,8 [85109.572129] Call Trace: [85109.572130] ([<>] (null)) [85109.572134] [<03ff800c81e4>] tap_sendmsg+0x384/0x430 [tap] [85109.572137] [<03ff801acdee>] vhost_tx_batch.isra.10+0x66/0xe0 [vhost_net] [85109.572138] [<03ff801ad61c>] handle_tx_copy+0x18c/0x568 [vhost_net] [85109.572140] [<03ff801adab4>] handle_tx+0xbc/0x100 [vhost_net] [85109.572145] [<03ff8019bbe8>] vhost_worker+0xc8/0x128 [vhost] [85109.572148] [<001690b8>] kthread+0x140/0x160 [85109.572152] [<00a84266>] kernel_thread_starter+0x6/0x10 [85109.572154] [<00a84260>] kernel_thread_starter+0x0/0x10 [85109.572155] Last Breaking-Event-Address: [85109.572156] [<0092e31c>] __skb_flow_dissect+0x1ec/0x1318 [85109.572158] ---[ end trace 97c040a6691bc000 ]---
Re: [PATCH v2] arm64: dts: sdm845: add video nodes
On 2018-11-30 12:09, Alexandre Courbot wrote:
On Wed, Nov 28, 2018 at 10:12 PM Malathi Gottam
wrote:
This adds video nodes to sdm845 based on the examples
in the bindings.
Signed-off-by: Malathi Gottam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 35
+++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0c9a2aa..4c9d6a4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -84,6 +84,11 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+
+ venus_region: memory@9580 {
+ reg = <0x0 0x9580 0x0 0x50>;
This patch depends on the firmware loader being fixed to not expect a
6MB area size. I think you can do it as follows:
For now, we are proceeding on adding node with memory region as 6MB.
Once we have the other patch for fixing firmware loader merged,
we can then try on recording the reserved area size.
I am posting updated patch with hard coded memory region.
Regards,
Malathi.
1) Record the reserved area size in the venus_core structure during
venus_load_fw(),
2) Use that area size in place of VENUS_FW_MEM_SIZE everywhere else in
the code.
That way we don't put any artificial limitation on the expected
firmware size, or on the reserved area in the DT matching a hardcoded
size.
Once you have this, the driver should work no matter what the size of
the reserved area is, provided the firmware first into it.
+ no-map;
+ };
};
cpus {
@@ -1103,5 +1108,35 @@
status = "disabled";
};
};
+
+ video-codec@aa0 {
+ compatible = "qcom,sdm845-venus";
+ reg = <0x0aa0 0xff000>;
+ interrupts = IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = < VENUS_GDSC>;
+ clocks = <
VIDEO_CC_VENUS_CTL_CORE_CLK>,
+< VIDEO_CC_VENUS_AHB_CLK>,
+<
VIDEO_CC_VENUS_CTL_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ iommus = <_smmu 0x10a0 0x8>,
+<_smmu 0x10b0 0x0>;
+ memory-region = <_region>;
+
+ video-core0 {
+ compatible = "venus-decoder";
+ clocks = <
VIDEO_CC_VCODEC0_CORE_CLK>,
+<
VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <
VCODEC0_GDSC>;
+ };
+
+ video-core1 {
+ compatible = "venus-encoder";
+ clocks = <
VIDEO_CC_VCODEC1_CORE_CLK>,
+<
VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <
VCODEC1_GDSC>;
+ };
We should probably have status = "disabled" here and enable this node
on a per-board basis?
Also, shouldn't we define the firmware subnode here too?
Cheers,
Alex.
--
1.9.1
Re: [PATCH] wil6210: remove set but not used variable 'wdev'
YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/wil6210/main.c: In function '_wil6210_disconnect':
> drivers/net/wireless/ath/wil6210/main.c:407:23: warning:
> variable 'wdev' set but not used [-Wunused-but-set-variable]
>
> It never used since commit ("e1b43407c034 wil6210: refactor disconnect flow")
>
> Signed-off-by: YueHaibing
> Reviewed-by: Maya Erez
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
3fe970e76b37 wil6210: remove set but not used variable 'wdev'
--
https://patchwork.kernel.org/patch/10713127/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wireless/wil6210: convert to DEFINE_SHOW_ATTRIBUTE
Yangtao Li wrote: > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 986b83488464 wil6210: convert to DEFINE_SHOW_ATTRIBUTE -- https://patchwork.kernel.org/patch/10709547/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
linux-next: manual merge of the akpm-current tree with the asm-generic tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/sh/include/asm/Kbuild
between commit:
2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
from the asm-generic tree and commit:
548211e87ba0 ("sh: include: convert to SPDX identifiers")
from the akpm-current 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.
--
Cheers,
Stephen Rothwell
diff --cc arch/sh/include/asm/Kbuild
index b15caf34813a,f4440779deab..
--- a/arch/sh/include/asm/Kbuild
+++ b/arch/sh/include/asm/Kbuild
@@@ -1,4 -1,4 +1,5 @@@
+ # SPDX-License-Identifier: GPL-2.0
+generated-y += syscall_table.h
generic-y += compat.h
generic-y += current.h
generic-y += delay.h
pgp5bYq55547x.pgp
Description: OpenPGP digital signature
[PATCH] gpu: anx7808: fix a missing check of return value
Both anx78xx_set_bits() and anx78xx_clear_bits() in the poweron process
may fail. The fix inserts checks for their return values. If the poweron
process fails, it calls anx78xx_poweroff().
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 26 ---
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index f8433c93f463..a57104c71739 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -610,20 +610,20 @@ static int anx78xx_enable_interrupts(struct anx78xx
*anx78xx)
return 0;
}
-static void anx78xx_poweron(struct anx78xx *anx78xx)
+static int anx78xx_poweron(struct anx78xx *anx78xx)
{
struct anx78xx_platform_data *pdata = >pdata;
- int err;
+ int err = 0;
if (WARN_ON(anx78xx->powered))
- return;
+ return err;
if (pdata->dvdd10) {
err = regulator_enable(pdata->dvdd10);
if (err) {
DRM_ERROR("Failed to enable DVDD10 regulator: %d\n",
err);
- return;
+ return err;
}
usleep_range(1000, 2000);
@@ -638,12 +638,18 @@ static void anx78xx_poweron(struct anx78xx *anx78xx)
gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
/* Power on registers module */
- anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2], SP_POWERDOWN_CTRL_REG,
+ err = anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2],
SP_POWERDOWN_CTRL_REG,
SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
- anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2], SP_POWERDOWN_CTRL_REG,
+ err |= anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2],
SP_POWERDOWN_CTRL_REG,
SP_REGISTER_PD | SP_TOTAL_PD);
+ if (err) {
+ anx78xx_poweroff(anx78xx);
+ return err;
+ }
anx78xx->powered = true;
+
+ return err;
}
static void anx78xx_poweroff(struct anx78xx *anx78xx)
@@ -1144,7 +1150,9 @@ static irqreturn_t anx78xx_hpd_threaded_handler(int irq,
void *data)
mutex_lock(>lock);
/* Cable is pulled, power on the chip */
- anx78xx_poweron(anx78xx);
+ err = anx78xx_poweron(anx78xx);
+ if (err)
+ DRM_ERROR("Failed to power on the chip: %d\n", err);
err = anx78xx_enable_interrupts(anx78xx);
if (err)
@@ -1379,7 +1387,9 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
}
/* Look for supported chip ID */
- anx78xx_poweron(anx78xx);
+ err = anx78xx_poweron(anx78xx);
+ if (err)
+ goto err_poweroff;
err = regmap_read(anx78xx->map[I2C_IDX_TX_P2], SP_DEVICE_IDL_REG,
);
--
2.17.2 (Apple Git-113)
Re: [PATCH RFC v2 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info
Hi Andrzej, Laurent,
Thanks for your review.
On 19/12/2018 08:50, Laurent Pinchart wrote:
> Hello,
>
> On Wednesday, 19 December 2018 09:26:08 EET Andrzej Hajda wrote:
>> On 30.11.2018 14:42, Neil Armstrong wrote:
>>> From: Zheng Yang
>>>
>>> To get input/output bus_format/enc_format dynamically, this patch
>>>
>>> introduce following funstion in plat_data:
>>> - get_input_bus_format
>>> - get_output_bus_format
>>> - get_enc_in_encoding
>>> - get_enc_out_encoding
>>
>> It seems fishy. On one side description says about dynamic resolution of
>> formats and encodings.
>>
>> On the other side these functions as only argument takes platform_data
>> which should be rather static.
They are callbacks to the "glue" code, similar the PHY and HPD callbacks,
they will return different encodings and formats depending on the current mode
being atomically set.
>>
>> Where is this "dynamic" thing? The only usage of these callbacks I have
>> found in next patches is also not dynamic, the functions just return
>> some static value.
in patch 7 & 8 we return the current glue dw_hdmi->input_bus_format
and dw_hdmi->output_bus_format set during the encoder atomic_check()
>>
>> Moreover function takes void* argument, which is again something
>> suspicious, why cannot you pass know structure?
Yes, we should also pass dw_hdmi along the dw_plat_data->phy_data we
already pass.
>>
>> And finally encoding usually should depend on display mode, it should
>> not depend only static data.
It does not, there are fallbacks already in place, where you can override
with static data (the bus encoding and format can be fixed) or dynamic
to solve the yuv420 format.
Amlogic pipeline can *only* output in YUV (444, 422 or 420) so I pushed
support for statically describing the input format and encoding using
V4L2 definitions.
>>
>>
>> What kind of problems do you want to solve here?
We try to solve 2 things :
- The YUV420 HDMI2.0 mode, but the DW-HDMI CSC cannot convert to/from YUV420, so
it's in passthrought only. So the encoder must output in yuv420 and the
controller
must know the input format and the output format, and this dynamically.
- Today the DW-HDMI forces RGB 8bit output, but we may prefer YUV444 or YU422
depending
on the sink and eventually output in 10, 12 or 16bit mode. This logic should
not be in the controller bridge code.
To solve these uses case, we put the logic in the encoder to determine what is
the DW-HDMI input format+encoding and the needed output format+encoding.
Today, the encoding callbacks are not used in this patchset, but they follow the
same scheme.
>
> I would add that this doesn't seem to be specific to dw-hdmi in any way. I'd
> prefer an API at the drm_bridge level to handle this.
Can you point me what you have in mind ? I'll be happy to implement it.
These callbacks are only an extension of the hdmi->plat_data->input_bus_format
and hdmi->plat_data->input_bus_encoding I introduced a few times ago.
I'd really like to solve this correctly, but still solve it at some point !
The YUV420 support is handy to easily support 4k60 for cheap and older TVs
without the hassle of SCDC and TMDS scrambling.
Neil
>
>>> Signed-off-by: Zheng Yang
>>> Signed-off-by: Neil Armstrong
>>> ---
>>>
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 +--
>>> include/drm/bridge/dw_hdmi.h | 5
>>> 2 files changed, 26 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>>> 4a9a24e854db..bd564ffdf18b 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1810,6 +1810,7 @@ static void hdmi_disable_overflow_interrupts(struct
>>> dw_hdmi *hdmi)>
>>> static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode
>>> *mode) {
>>>
>>> int ret;
>>>
>>> + void *data = hdmi->plat_data->phy_data;
>>>
>>> hdmi_disable_overflow_interrupts(hdmi);
>>>
>>> @@ -1821,10 +1822,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
>>> struct drm_display_mode *mode)>
>>> dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
>>>
>>> }
>>>
>>> - if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
>>> - (hdmi->vic == 21) || (hdmi->vic == 22) ||
>>> - (hdmi->vic == 2) || (hdmi->vic == 3) ||
>>> - (hdmi->vic == 17) || (hdmi->vic == 18))
>>> + if (hdmi->plat_data->get_enc_out_encoding)
>>> + hdmi->hdmi_data.enc_out_encoding =
>>> + hdmi->plat_data->get_enc_out_encoding(data);
>>> + else if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
>>> +(hdmi->vic == 21) || (hdmi->vic == 22) ||
>>> +(hdmi->vic == 2) || (hdmi->vic == 3) ||
>>> +(hdmi->vic == 17) || (hdmi->vic == 18))
>>>
>>> hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_601;
>>>
>>> else
>>>
>>>
Re: [PATCH 1/3] ath6kl: Only use match sets when firmware supports it
Kyle Roeschley wrote:
> Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
> merged the probed and matched SSID lists before sending them to the
> firmware. In the process, it assumed match set support is always available
> in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check
> that the firmware supports matching SSIDs in scheduled scans before setting
> MATCH_SSID_FLAG.
>
> Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
> Signed-off-by: Kyle Roeschley
> Signed-off-by: Kalle Valo
3 patches applied to ath-next branch of ath.git, thanks.
fb376a495fbd ath6kl: Only use match sets when firmware supports it
5803c12816c4 ath6kl: Fix off by one error in scan completion
192a986d964c ath6kl: Use debug instead of error message when disabled
--
https://patchwork.kernel.org/patch/10674651/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: remove exofs, the T10 OSD code and block/scsi bidi support V3
On Wed, Dec 19, 2018 at 09:01:53PM -0500, Douglas Gilbert wrote: >> 1) reduce the size of every kernel with block layer support, and >> even more for every kernel with scsi support > > By proposing the removal of bidi support from the block layer, it isn't > just the SCSI subsystem that will be impacted. Those NVMe documents > that you referred me to earlier in the year, in the command tables > in 1.3c and earlier you have noticed the 2 bit direction field and > what 11b means? Even if there aren't any bidi NVMe commands *** yet, > the fact that NVMe's 64 byte command format has provision for 4 > (not 2) independent data transfers (data + meta, for each direction). > Surely NVMe will sooner or later take advantage of those ... a > command like READ GATHERED comes to mind. NVMe on the other hand does have support for separate read and write buffers as in the current SCSI bidi support, as it encodes the data transfers in that SQE. So IFF NVMe does bidi commands it would have to use a single buffer for data in/out, which can be easily done in the block layer without the current bidi support that chains two struct request instances for data in and data out. >> 2) reduce the size of the critical struct request structure by >> 128 bits, thus reducing the memory used by every blk-mq driver >> significantly, never mind the cache effects > > Hmm, one pointer (that is null in the non-bidi case) should be enough, > that's 64 or 32 bits. Due to the way we use request chaining we need two fields at the moment. ->special and ->next_rq. If we'd refactor the whole thing for the basically non-existent user we could indeed probably get it down to a single pointer. > While on the subject of bidi, the order of transfers: is the data-out > (to the target) always before the data-in or is it the target device > that decides (depending on the semantics of the command) who is first? The way I read SAM data needs to be transferred to the device for processing first, then the processing occurs and then it is transferred out, so the order seems fixed. > > Doug Gilbert > > *** there could already be vendor specific bidi NVMe commands out > there (ditto for SCSI) For NVMe they'd need to transfer data in and out in the same buffer to sort work, and even then only if we don't happen to be bounce buffering using swiotlb, or using a network transport. Similarly for SCSI only iSCSI at the moment supports bidi CDBs, so we could have applications using vendor specific bidi commands on iSCSI, which is exactly what we're trying to find out, but it is a bit of a very niche use case.
[PATCH] powerpc/8xx: Allow pinning IMMR TLB when using early debug console
CONFIG_EARLY_DEBUG_CPM requires IMMR area TLB to be pinned otherwise it doesn't survive MMU_init, and the boot fails. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 7996ec33f1b4..45aed802ba86 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -1192,7 +1192,7 @@ config PIN_TLB_DATA config PIN_TLB_IMMR bool "Pinned TLB for IMMR" - depends on PIN_TLB + depends on PIN_TLB || PPC_EARLY_DEBUG_CPM default y config PIN_TLB_TEXT -- 2.13.3
[PATCH] iio: ad9523: fix a missing check of return value
If ad9523_write() fails, indio_dev may get incorrect data. The fix
inserts a check for the return value of ad9523_write(), and it fails,
returns an error.
Signed-off-by: Kangjie Lu
---
drivers/iio/frequency/ad9523.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c
index f3f94fbdd20a..3f9be69499ec 100644
--- a/drivers/iio/frequency/ad9523.c
+++ b/drivers/iio/frequency/ad9523.c
@@ -943,11 +943,14 @@ static int ad9523_setup(struct iio_dev *indio_dev)
}
}
- for_each_clear_bit(i, _mask, AD9523_NUM_CHAN)
- ad9523_write(indio_dev,
+ for_each_clear_bit(i, _mask, AD9523_NUM_CHAN) {
+ ret = ad9523_write(indio_dev,
AD9523_CHANNEL_CLOCK_DIST(i),
AD9523_CLK_DIST_DRIVER_MODE(TRISTATE) |
AD9523_CLK_DIST_PWR_DOWN_EN);
+ if (ret < 0)
+ return ret;
+ }
ret = ad9523_write(indio_dev, AD9523_POWER_DOWN_CTRL, 0);
if (ret < 0)
--
2.17.2 (Apple Git-113)
Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline
Hi Michal,
WIth this patch applied on the old one, I got the following message.
Please get it from attachment.
Thanks,
Pingfan
On Mon, Dec 17, 2018 at 9:29 PM Michal Hocko wrote:
>
> On Thu 13-12-18 17:04:01, Pingfan Liu wrote:
> [...]
> > > > @@ -592,6 +600,10 @@ static int __init numa_register_memblks(struct
> > > > numa_meminfo *mi)
> > > > continue;
> > > >
> > > > alloc_node_data(nid);
> > > > + if (!end)
> > > > + init_memory_less_node(nid);
> >
> > Just have some opinion on this. Here is two issue. First, is this node
> > online?
>
>
> It shouldn't be as it doesn't have any memory.
>
> > I do not see node_set_online() is called in this patch.
>
> It is below for nodes with some memory.
>
> > Second, if node is online here, then init_memory_less_node->
> > free_area_init_node is called duplicated when free_area_init_nodes().
> > This should be a critical design issue.
>
> I am still trying to wrap my head around the expected code flow here.
> numa_init does the following for all CPUs within nr_cpu_ids (aka nr_cpus
> aware).
> if (!node_online(nid))
> numa_clear_node(i);
>
> I do not really understand why do we do this. But this enforces
> init_cpu_to_node to do init_memory_less_node (with the current upstream
> code) and that will mark the node online again and zonelists are built
> properly. My patch couldn't help in that respect because the node is
> offline (as it should be IMHO).
>
> So let's try another attempt with some larger surgery (on top of the
> previous patch). It will also dump the zonelist after it is built for
> each node. Let's see whether something more is lurking there.
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index a5548fe668fb..eb7c905d5d86 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -525,19 +525,6 @@ static void __init numa_clear_kernel_node_hotplug(void)
> }
> }
>
> -static void __init init_memory_less_node(int nid)
> -{
> - unsigned long zones_size[MAX_NR_ZONES] = {0};
> - unsigned long zholes_size[MAX_NR_ZONES] = {0};
> -
> - free_area_init_node(nid, zones_size, 0, zholes_size);
> -
> - /*
> -* All zonelists will be built later in start_kernel() after per cpu
> -* areas are initialized.
> -*/
> -}
> -
> static int __init numa_register_memblks(struct numa_meminfo *mi)
> {
> unsigned long uninitialized_var(pfn_align);
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5411de93a363..99252a0b6551 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2045,6 +2045,8 @@ extern void __init pagecache_init(void);
> extern void free_area_init(unsigned long * zones_size);
> extern void __init free_area_init_node(int nid, unsigned long * zones_size,
> unsigned long zone_start_pfn, unsigned long *zholes_size);
> +extern void init_memory_less_node(int nid);
> +
> extern void free_initmem(void);
>
> /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 2ec9cc407216..a5c035fd6307 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5234,6 +5234,8 @@ static void build_zonelists(pg_data_t *pgdat)
> int node, load, nr_nodes = 0;
> nodemask_t used_mask;
> int local_node, prev_node;
> + struct zone *zone;
> + struct zoneref *z;
>
> /* NUMA-aware ordering of nodes */
> local_node = pgdat->node_id;
> @@ -5259,6 +5261,11 @@ static void build_zonelists(pg_data_t *pgdat)
>
> build_zonelists_in_node_order(pgdat, node_order, nr_nodes);
> build_thisnode_zonelists(pgdat);
> +
> + pr_info("node[%d] zonelist: ", pgdat->node_id);
> + for_each_zone_zonelist(zone, z,
> >node_zonelists[ZONELIST_FALLBACK], MAX_NR_ZONES-1)
> + pr_cont("%d:%s ", zone_to_nid(zone), zone->name);
> + pr_cont("\n");
> }
>
> #ifdef CONFIG_HAVE_MEMORYLESS_NODES
> @@ -5447,6 +5454,20 @@ void __ref build_all_zonelists(pg_data_t *pgdat)
> #endif
> }
>
> +void __init init_memory_less_node(int nid)
> +{
> + unsigned long zones_size[MAX_NR_ZONES] = {0};
> + unsigned long zholes_size[MAX_NR_ZONES] = {0};
> +
> + free_area_init_node(nid, zones_size, 0, zholes_size);
> + __build_all_zonelists(NODE_DATA(nid));
> +
> + /*
> +* All zonelists will be built later in start_kernel() after per cpu
> +* areas are initialized.
> +*/
> +}
> +
> /* If zone is ZONE_MOVABLE but memory is mirrored, it is an overlapped init
> */
> static bool __meminit
> overlap_memmap_init(unsigned long zone, unsigned long *pfn)
> --
> Michal Hocko
> SUSE Labs
[0.00] Linux version 4.20.0-rc7+
[0.00] Command line: root=/dev/mapper/xx_dell--per7425--03-root ro
crashkernel=500M rd.lvm.lv=xx_dell-per7425-03/root
rd.lvm.lv=xx_dell-per7425-03/swap console=ttyS0,115200n81
earlyprintk=ttyS0,115200n81
[0.00] x86/fpu:
Re: [PATCH] drm/ioctl: Fix Spectre v1 vulnerabilities
On Wed, Dec 19, 2018 at 06:00:15PM -0600, Gustavo A. R. Silva wrote:
> nr is indirectly controlled by user-space, hence leading to a
> potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue
> 'dev->driver->ioctls' [r]
> drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue
> 'drm_ioctls' [r] (local cap)
> drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre
> issue 'drm_ioctls' [r] (local cap)
>
> Fix this by sanitizing nr before using it to index dev->driver->ioctls
> and drm_ioctls.
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
lgtm and I think there's no other obvious place where we need
array_index_nospec in drm core. Applied to drm-misc-fixes.
-Daniel
> ---
> drivers/gpu/drm/drm_ioctl.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 94bd872d56c4..7e6746b2d704 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -37,6 +37,7 @@
>
> #include
> #include
> +#include
>
> /**
> * DOC: getunique and setversion story
> @@ -800,13 +801,17 @@ long drm_ioctl(struct file *filp,
>
> if (is_driver_ioctl) {
> /* driver ioctl */
> - if (nr - DRM_COMMAND_BASE >= dev->driver->num_ioctls)
> + unsigned int index = nr - DRM_COMMAND_BASE;
> +
> + if (index >= dev->driver->num_ioctls)
> goto err_i1;
> - ioctl = >driver->ioctls[nr - DRM_COMMAND_BASE];
> + index = array_index_nospec(index, dev->driver->num_ioctls);
> + ioctl = >driver->ioctls[index];
> } else {
> /* core ioctl */
> if (nr >= DRM_CORE_IOCTL_COUNT)
> goto err_i1;
> + nr = array_index_nospec(nr, DRM_CORE_IOCTL_COUNT);
> ioctl = _ioctls[nr];
> }
>
> @@ -888,6 +893,7 @@ bool drm_ioctl_flags(unsigned int nr, unsigned int *flags)
>
> if (nr >= DRM_CORE_IOCTL_COUNT)
> return false;
> + nr = array_index_nospec(nr, DRM_CORE_IOCTL_COUNT);
>
> *flags = drm_ioctls[nr].flags;
> return true;
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] nvme-pci: fix dbbuf_sq_db point to freed memory
The case is that nvme device support NVME_CTRL_OACS_DBBUF_SUPP, and
return failed when the driver sent nvme_admin_dbbuf. The nvmeq->dbbuf_sq_db
point to freed memory, as nvme_dbbuf_set is called behind nvme_dbbuf_init.
Change-Id: Ief2a5877cb008d3c29cf99053f80fecc9b8db1db
Signed-off-by: lulina
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index da39729..2e11980 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -240,16 +240,25 @@ static int nvme_dbbuf_dma_alloc(struct nvme_dev *dev)
static void nvme_dbbuf_dma_free(struct nvme_dev *dev)
{
unsigned int mem_size = nvme_dbbuf_size(dev->db_stride);
+ unsigned int i;
if (dev->dbbuf_dbs) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_dbs, dev->dbbuf_dbs_dma_addr);
dev->dbbuf_dbs = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i]->dbbuf_sq_db = NULL;
+ dev->queues[i]->dbbuf_cq_db = NULL;
+ }
}
if (dev->dbbuf_eis) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_eis, dev->dbbuf_eis_dma_addr);
dev->dbbuf_eis = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i]->dbbuf_sq_ei = NULL;
+ dev->queues[i]->dbbuf_cq_ei = NULL;
+ }
}
}
--
1.8.3.1
Re: [PATCH 6/7] drm: Remove use of drm_mode_object
On Wed, Dec 19, 2018 at 07:28:36PM -0200, Shayenne Moura wrote:
> This patch removes the drm_mode_object prints, evaluation and use from
> drm_display_mode objects used in drm files. It removes dependency from
> drm_mode_object.
>
> Signed-off-by: Shayenne Moura
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 5 ++---
> drivers/gpu/drm/drm_modes.c | 5 -
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a3c81850e755..cc5cc8d109a2 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -386,9 +386,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> if (!encoder_funcs)
> continue;
>
> - DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%d:%s]\n",
> - encoder->base.id, encoder->name,
> - mode->base.id, mode->name);
> + DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%s]\n",
> + encoder->base.id, encoder->name, mode->name);
> if (encoder_funcs->mode_set)
> encoder_funcs->mode_set(encoder, mode, adjusted_mode);
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 24a750436559..e2689afdcf50 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -71,11 +71,6 @@ struct drm_display_mode *drm_mode_create(struct drm_device
> *dev)
> if (!nmode)
> return NULL;
>
> - if (drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_MODE)) {
> - kfree(nmode);
> - return NULL;
> - }
You seem to have lost the 3rd hunk here compared to the previous version.
For reordering patches the best way is to use
$ git rebase --interactive
which fires up a text editor where you can reorder the patches as you see
fit. That way you don't have to touch them and risk breaking something.
Another thing: When resending patches unchanged, and your previous version
has received r-b/a-b tags, please include them. That way people know what
still needs to be reviewed and what is already reviewed. I think there was
also some other patches than this one that I reviewed already, can you pls
redo the patch series with r-b tags included, patch commit log (where you
did change something) added and then resend?
Threading looks good now.
Thanks, Daniel
> -
> return nmode;
> }
> EXPORT_SYMBOL(drm_mode_create);
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/7] drm: msm: Cleanup drm_display_mode print string
On Wed, Dec 19, 2018 at 07:21:41PM -0200, Shayenne Moura wrote:
> This patch adjust the print string of drm_display_mode object
> to remove drm_mode_object dependency in msm files.
>
> Signed-off-by: Shayenne Moura
Please have a per-patch changelog of what changed compared to earlier
versions, e.g. here:
v2: Use DRM_MODE_FMT/ARG macros (Daniel).
Or something like that. Patch series threading looks correct now.
-Daniel
> ---
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 10 ++
> drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 9 +
> drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 9 +
> drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 9 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 9 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 9 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 9 +
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 9 +
> drivers/gpu/drm/msm/edp/edp_bridge.c | 9 +
> 9 files changed, 10 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
> index 457c29dba4a1..7b028f778960 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
> @@ -244,14 +244,8 @@ static void mdp4_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
>
> mode = >state->adjusted_mode;
>
> - DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
> - mdp4_crtc->name, mode->base.id, mode->name,
> - mode->vrefresh, mode->clock,
> - mode->hdisplay, mode->hsync_start,
> - mode->hsync_end, mode->htotal,
> - mode->vdisplay, mode->vsync_start,
> - mode->vsync_end, mode->vtotal,
> - mode->type, mode->flags);
> + DBG("%s: set mode: " DRM_MODE_FMT,
> + mdp4_crtc->name, DRM_MODE_ARG(mode));
>
> mdp4_write(mdp4_kms, REG_MDP4_DMA_SRC_SIZE(dma),
> MDP4_DMA_SRC_SIZE_WIDTH(mode->hdisplay) |
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
> index 6a1ebdace391..f2009e317820 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
> @@ -58,14 +58,7 @@ static void mdp4_dsi_encoder_mode_set(struct drm_encoder
> *encoder,
>
> mode = adjusted_mode;
>
> - DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
> - mode->base.id, mode->name,
> - mode->vrefresh, mode->clock,
> - mode->hdisplay, mode->hsync_start,
> - mode->hsync_end, mode->htotal,
> - mode->vdisplay, mode->vsync_start,
> - mode->vsync_end, mode->vtotal,
> - mode->type, mode->flags);
> + DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG()):
>
> ctrl_pol = 0;
> if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
> index ba8e587f734b..f6bc86a35d8d 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
> @@ -104,14 +104,7 @@ static void mdp4_dtv_encoder_mode_set(struct drm_encoder
> *encoder,
>
> mode = adjusted_mode;
>
> - DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
> - mode->base.id, mode->name,
> - mode->vrefresh, mode->clock,
> - mode->hdisplay, mode->hsync_start,
> - mode->hsync_end, mode->htotal,
> - mode->vdisplay, mode->vsync_start,
> - mode->vsync_end, mode->vtotal,
> - mode->type, mode->flags);
> + DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
>
> mdp4_dtv_encoder->pixclock = mode->clock * 1000;
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
> index 2bfb39082f54..d47b8f4af991 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
> @@ -273,14 +273,7 @@ static void mdp4_lcdc_encoder_mode_set(struct
> drm_encoder *encoder,
>
> mode = adjusted_mode;
>
> - DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
> - mode->base.id, mode->name,
> - mode->vrefresh, mode->clock,
> - mode->hdisplay, mode->hsync_start,
> - mode->hsync_end, mode->htotal,
> - mode->vdisplay, mode->vsync_start,
> - mode->vsync_end, mode->vtotal,
> -
[PATCH] media: drx: fix a missing check of return value
Function drxj_dap_write_reg16(), which writes data to buffer, may fail.
We need to check if it fails, and if so, we should goto error.
Otherwise, the buffer will have incorrect data.
Signed-off-by: Kangjie Lu
---
drivers/media/dvb-frontends/drx39xyj/drxj.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index 551b7d65fa66..d105125bc1c3 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -2136,9 +2136,13 @@ int drxj_dap_atomic_read_write_block(struct
i2c_device_addr *dev_addr,
word = ((u16) data[2 * i]);
word += (((u16) data[(2 * i) + 1]) << 8);
- drxj_dap_write_reg16(dev_addr,
+ rc = drxj_dap_write_reg16(dev_addr,
(DRXJ_HI_ATOMIC_BUF_START + i),
word, 0);
+ if (rc) {
+ pr_err("error %d\n", rc);
+ goto rw_error;
+ }
}
}
--
2.17.2 (Apple Git-113)
Re: [PATCH v3] irqchip/mmp: only touch the PJ4 & FIQ bits on enable/disable
Marc Zyngier wrote:
> On 19/12/2018 18:37, Lubomir Rintel wrote:
>> On Wed, 2018-12-19 at 18:29 +, Marc Zyngier wrote:
>>> On 19/12/2018 17:28, Lubomir Rintel wrote:
On an OLPC XO 1.75 machine, the "security processor" handles the GPIO 71
and 72 interrupts. Don't reset the "route to SP" bit (4).
I'm just assuming the bit 4 is the "route to SP" bit -- it fixes the
SP-based keyboard for me and defines
ICU_INT_ROUTE_SP_IRQ to be 1 << 4. When asked for a data sheet, Marvell
was not helpful.
Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
---
Changes since v2:
- Correct subsystem maintainers on Cc (irqchip)
Changes since v1:
- Adjusted wording & ack from Pavel
drivers/irqchip/irq-mmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 25f32e1d7764..1ed38f9f1d0a 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -190,7 +190,7 @@ static const struct mmp_intc_conf mmp_conf = {
static const struct mmp_intc_conf mmp2_conf = {
.conf_enable= 0x20,
.conf_disable = 0x0,
- .conf_mask = 0x7f,
+ .conf_mask = 0x60,
>>>
>>> You seem to have identified that ICU_INT_ROUTE_PJ4_IRQ and
>>> ICU_INT_ROUTE_PJ4_FIQ bits are the only ones to be touched. So why don't
>>> you use these constants? This number soup is quite unhealthy.
>>
>> Yeah, but those #defines live in mach-mmp, so some moving would be
>> necessary. If you indeed prefer that then I can follow up with a patch
>> that does that.
>
> Given that nothing in the tree uses these #defines at all, they can be
> swiftly moved in one single go.
Will do.
>>> It'd be good to Cc some of the folks who initially wrote this code
>>> (Haojian Zhuang, Eric Miao -- assuming they are still around) and get
>>> some testing on a non OLPC platform, just to make sure there is no
>>> regression due to this. I have the nagging feeling that this could be a
>>> platform specific thing rather than a universal setting.
>>
>> They've been Cc'd on previous spins of the patch (and tens of other
>> mmp-related patches that were in circulation lately), but they never
>> returned a response. It is safe to assume they're AWOL.
>
> OK, so what else in the known universe uses the same SoC and runs
> mainline? This really needs wider testing if we can't get information
> from the MV folks.
While I can't possibly know for sure, I think it's fairly sure there are no
users beyond OLPC. The only MMP2 board that would run this was "Brownstone"
(that can't be obtained anymore) and the whole mmp2-dt support was
unbootable until recently without anyone noticing.
I think we're safe here. If anyone with a Brownstone board running mainline
exists (unlikely), linux-next + a few RCs are going to give them a good
chance to test this,
>
> Thanks,
>
> M.
Cheers,
Lubo
Re: linux-next: manual merge of the net-next tree with the net tree
On Thu, Dec 20, 2018 at 4:47 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>
> between commit:
>
> 8956f0014ea5 ("net/mlx5e: Fix default amount of channels for VF
> representors")
>
> from the net tree and commit:
>
> d9ee0491c2ff ("net/mlx5e: Use dedicated uplink vport netdev representor")
>
> from the net-next tree.
>
> I fixed it up (I just used the net-next tree version) and can carry the
> fix as necessary. [..]
Yes, this is correct, thanks!
Re: [PATCH v2 0/4] serial: uartps: Driver updates
Hi, On 19. 12. 18 19:40, Maarten Brock wrote: > Hello Michal, > > On 2018-12-18 13:18, Michal Simek wrote: >> Hi, >> >> I am sending 4 patches in series to fix some issues we found. >> Patches were sent separately but I have been asked to send them in >> serial that's why I am also adding cover letter to explain this v2 >> version. >> >> Thanks, >> Michal > > I'm wondering why, when reading the linux-serial mailing list, I can > only see this cover letter. > Are you perhaps using a different To/Cc for the actual patches? And if > so, is that on purpose? > I have checked linux-serial mailing list and I see all of them there. https://www.spinics.net/lists/linux-serial/ Individual here. https://www.spinics.net/lists/linux-serial/msg32919.html https://www.spinics.net/lists/linux-serial/msg32916.html https://www.spinics.net/lists/linux-serial/msg32917.html https://www.spinics.net/lists/linux-serial/msg32918.html Also I see linux-serial@ in CC in all emails I have sent. Thanks, Michal
Re: [PATCH] ipw2x00: cleanup dead code
YueHaibing wrote: > Fix smatch warning: > > drivers/net/wireless/intel/ipw2x00/ipw2100.c:5606 > shim__set_security() warn: always true condition '(sec->active_key <= 3) => > (0-3 <= 3)' > drivers/net/wireless/intel/ipw2x00/ipw2200.c:10725 > shim__set_security() warn: always true condition '(sec->active_key <= 3) => > (0-3 <= 3)' > > Signed-off-by: YueHaibing Patch applied to wireless-drivers-next.git, thanks. 90a8c74a8d7b ipw2x00: cleanup dead code -- https://patchwork.kernel.org/patch/10736741/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()
Jia-Ju Bai wrote: > The function cw1200_bss_info_changed() and cw1200_hw_scan() can be > concurrently executed. > The two functions both access a possible shared variable "frame.skb". > > This shared variable is freed by dev_kfree_skb() in cw1200_upload_beacon(), > which is called by cw1200_bss_info_changed(). The free operation is > protected by a mutex lock "priv->conf_mutex" in cw1200_bss_info_changed(). > > In cw1200_hw_scan(), this shared variable is accessed without the > protection of the mutex lock "priv->conf_mutex". > Thus, concurrency use-after-free bugs may occur. > > To fix these bugs, the original calls to mutex_lock(>conf_mutex) and > mutex_unlock(>conf_mutex) are moved to the places, which can > protect the accesses to the shared variable. > > Signed-off-by: Jia-Ju Bai Patch applied to wireless-drivers-next.git, thanks. 4f68ef64cd7f cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan() -- https://patchwork.kernel.org/patch/10730469/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v2] drm/bochs: add edid present check
Check first two header bytes before trying to read the edid blob, to avoid the log being spammed in case qemu has no edid support (old qemu or edid turned off). Fixes: 01f23459cf drm/bochs: add edid support. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/bochs/bochs_hw.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index c90a0d492f..e1f8ffce00 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -89,6 +89,14 @@ int bochs_hw_load_edid(struct bochs_device *bochs) if (!bochs->mmio) return -1; + /* +* Check first two EDID blob header bytes to figure whenever +* edid support is enabled in qemu. +*/ + if (readb(bochs->mmio + 0) != 0x00 || + readb(bochs->mmio + 1) != 0xff) + return -1; + kfree(bochs->edid); bochs->edid = drm_do_get_edid(>connector, bochs_get_edid_block, bochs); -- 2.9.3
Re: [PATCH 32/41] scsi: myrb: Mark expected switch fall-throughs
On 12/20/18 1:07 AM, Gustavo A. R. Silva wrote:
Hi,
Friendly ping:
Who can ack or review this patch, please?
Thanks
--
Gustavo
On 11/27/18 10:32 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1465234 ("Missing break in switch")
Addresses-Coverity-ID: 1465238 ("Missing break in switch")
Addresses-Coverity-ID: 1465242 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/scsi/myrb.c | 3 +++
1 file changed, 3 insertions(+)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
Easy Kernel Patch
This is my first patch submitted. I hope I can finally say I have a commit in the Linux source code :) From 1ce6365d07c734cea9965d3135dd64e2641021ef Mon Sep 17 00:00:00 2001 From: kindlehl Date: Wed, 19 Dec 2018 22:36:22 -0800 Subject: [PATCH] Removed twin forward-declaration of struct device Signed-off-by: kindlehl --- include/linux/pm.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/pm.h b/include/linux/pm.h index e723b78d8357..d33147db9400 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -51,8 +51,6 @@ static inline void pm_vt_switch_unregister(struct device *dev) * Device power management */ -struct device; - #ifdef CONFIG_PM extern const char power_group_name[]; /* = "power" */ #else -- 2.19.1
Re: [PATCH] cw1200: convert to DEFINE_SHOW_ATTRIBUTE
Yangtao Li wrote: > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li Patch applied to wireless-drivers-next.git, thanks. cc4dc97ffc69 cw1200: convert to DEFINE_SHOW_ATTRIBUTE -- https://patchwork.kernel.org/patch/10709559/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v1 01/12] dt-bindings: usb: add support for dwc3 controller on HiSilicon SoCs
Hi,
Rob Herring writes:
>> +Example:
>> + usb3: hisi_dwc3 {
>> + compatible = "hisilicon,hi3660-dwc3";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + clocks = <_ctrl HI3660_CLK_ABB_USB>,
>> + <_ctrl HI3660_ACLK_GATE_USB3OTG>;
>> + clock-names = "clk_usb3phy_ref", "aclk_usb3otg";
>> + assigned-clocks = <_ctrl HI3660_ACLK_GATE_USB3OTG>;
>> + assigned-clock-rates = <22900>;
>> + resets = <_rst 0x90 8>,
>> + <_rst 0x90 7>,
>> + <_rst 0x90 6>,
>> + <_rst 0x90 5>;
>> +
>> + dwc3: dwc3@ff10 {
>
> Please combine these into a single node. Unless you have a wrapper with
> registers, you don't need these 2 nodes. Clocks and reset can go in the
> dwc3 node.
>
>> >>>
>> >>> According to the DT spec, the node names should be generic, not
>> >>> chip specific, i.e. usb@ff10 in this case.
>> >>>
>> >>
>> >> Do you mean it should be usb@ff10: dwc3@ff10 ?
>> >
>> > dwc3: usb@ff10
>> >
>> > "dwc3:" is a label, not name.
>>
>> I use the node name "dwc3@ff10" according to
>> Documentation/devicetree/bindings/usb/dwc3.txt
>> and documentations of vendor drivers, i.e. qcom,dwc3.txt, rockchip,dwc3.txt.
>>
>> In these documentations, the dwc3 sub-node name uses "dwc3@".
>>
>> I think it is better to be same as the other vendor's dwc3 drivers.
>
> It's not. The other bindings are wrong. Follow the DT Spec.
what's wrong about them? They clearly describe the HW:
1) a company-specific glue/adaptation/integration IP
2) a generic licensed IP inside it
dwc3.ko is compatible with Synopsys' documentation and there's only one
incarnation of dwc3. Everything that can be detected in runtime, we do
so. Everything that can't, we use quirk flags. Keep in mind dwc3.ko is
also used as is by non-DT systems where we can't simply change a
compatible flag.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] rtlwifi: Fix non-working BSS STA mode
Kai-Heng Feng wrote: > Once BSS STA mode gets started, it can be scanned by other clients but > cannot entablish a connection. > > Turns out the set_bcn_reg() and its *_set_beacon_related_registers() > callbacks never get called so it has problem beaconing. > > Enable the function in rtl_op_bss_info_changed() can make BSS STA mode > start to work. > > Signed-off-by: Kai-Heng Feng The commit log is quite misleading. It implies that the client mode is broken for all rtlwifi hardware and that can't be the case, otherwise we would be flooded by bug reports. So please improve the commit log and describe clearly the problem you are solving. -- https://patchwork.kernel.org/patch/10725537/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[RFC PATCH v2 0/3] KASAN for nohash PPC32
This serie adds KASAN support to nohash PPC32 Tested on 8xx Changes in v2: - Rebased. - Using __set_pte_at() to build the early table. - Worked around and got rid of the patch adding asm/page.h in asm/pgtable-types.h ==> might be fixed independently but needed for this serie. In principle, this should also work on the 603. For now I have not been able to boot, it stops before early console is active, so I'm quite blind at the moment and don't really know what's wrong. Any idea ? For hash32 (not 603), it cannot work as is because due to HASHPTE flag, we can't use the same pagetable for several PGD entries. Christophe Leroy (3): powerpc/mm: prepare kernel for KAsan on PPC32 powerpc/32: Move early_init() in a separate file powerpc/nohash32: Add KASAN support arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/kasan.h | 22 + arch/powerpc/include/asm/nohash/32/pgtable.h | 2 + arch/powerpc/include/asm/ppc_asm.h | 5 ++ arch/powerpc/include/asm/setup.h | 5 ++ arch/powerpc/include/asm/string.h| 14 ++ arch/powerpc/kernel/Makefile | 5 +- arch/powerpc/kernel/cputable.c | 4 +- arch/powerpc/kernel/early_32.c | 35 + arch/powerpc/kernel/setup-common.c | 2 + arch/powerpc/kernel/setup_32.c | 31 ++-- arch/powerpc/lib/Makefile| 2 + arch/powerpc/lib/copy_32.S | 9 ++-- arch/powerpc/mm/Makefile | 3 ++ arch/powerpc/mm/dump_linuxpagetables.c | 8 +++ arch/powerpc/mm/kasan_init.c | 73 arch/powerpc/mm/mem.c| 4 ++ 17 files changed, 191 insertions(+), 34 deletions(-) create mode 100644 arch/powerpc/include/asm/kasan.h create mode 100644 arch/powerpc/kernel/early_32.c create mode 100644 arch/powerpc/mm/kasan_init.c -- 2.13.3
[RFC PATCH v2 1/3] powerpc/mm: prepare kernel for KAsan on PPC32
In kernel/cputable.c, explicitly use memcpy() in order
to allow GCC to replace it with __memcpy() when KASAN is
selected.
Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is
enabled"), memset() can be used before activation of the cache,
so no need to use memset_io() for zeroing the BSS.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 4 ++--
arch/powerpc/kernel/setup_32.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 2da01340c84c..9ea031b05f19 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2145,7 +2145,7 @@ void __init set_cur_cpu_spec(struct cpu_spec *s)
struct cpu_spec *t = _cpu_spec;
t = PTRRELOC(t);
- *t = *s;
+ memcpy(t, s, sizeof(*t));
*PTRRELOC(_cpu_spec) = _cpu_spec;
}
@@ -2160,7 +2160,7 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned
long offset,
old = *t;
/* Copy everything, then do fixups */
- *t = *s;
+ memcpy(t, s, sizeof(*t));
/*
* If we are overriding a previous value derived from the real
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 972c98d1e208..00b8f54fed29 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -74,10 +74,8 @@ notrace unsigned long __init early_init(unsigned long dt_ptr)
{
unsigned long offset = reloc_offset();
- /* First zero the BSS -- use memset_io, some platforms don't have
-* caches on yet */
- memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
- __bss_stop - __bss_start);
+ /* First zero the BSS */
+ memset(PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start);
/*
* Identify the CPU type and fix up code sections
--
2.13.3
[RFC PATCH v2 3/3] powerpc/nohash32: Add KASAN support
This patch adds KASAN support for nohash PPC32.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/kasan.h | 22 +
arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
arch/powerpc/include/asm/ppc_asm.h | 5 ++
arch/powerpc/include/asm/setup.h | 5 ++
arch/powerpc/include/asm/string.h| 14 ++
arch/powerpc/kernel/Makefile | 3 ++
arch/powerpc/kernel/setup-common.c | 2 +
arch/powerpc/kernel/setup_32.c | 3 ++
arch/powerpc/lib/Makefile| 2 +
arch/powerpc/lib/copy_32.S | 9 ++--
arch/powerpc/mm/Makefile | 3 ++
arch/powerpc/mm/dump_linuxpagetables.c | 8 +++
arch/powerpc/mm/kasan_init.c | 73
arch/powerpc/mm/mem.c| 4 ++
15 files changed, 153 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/include/asm/kasan.h
create mode 100644 arch/powerpc/mm/kasan_init.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8ea7c2c02cbf..44be55c087be 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -174,6 +174,7 @@ config PPC
select GENERIC_TIME_VSYSCALL
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_KASAN if PPC32 && PPC_MMU_NOHASH
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
new file mode 100644
index ..3c2f98c40307
--- /dev/null
+++ b/arch/powerpc/include/asm/kasan.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifndef __ASSEMBLY__
+
+#include
+#include
+#include
+
+#define KASAN_SHADOW_SCALE_SHIFT 3
+#define KASAN_SHADOW_SIZE ((~0UL - PAGE_OFFSET + 1) >>
KASAN_SHADOW_SCALE_SHIFT)
+
+#define KASAN_SHADOW_START (ALIGN_DOWN(FIXADDR_START - KASAN_SHADOW_SIZE,
PGDIR_SIZE))
+#define KASAN_SHADOW_END(KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
+#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_START - (PAGE_OFFSET >>
KASAN_SHADOW_SCALE_SHIFT))
+
+void kasan_early_init(void);
+void kasan_init(void);
+
+#endif
+#endif
diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h
b/arch/powerpc/include/asm/nohash/32/pgtable.h
index bed433358260..b3b52f02be1a 100644
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@ -71,6 +71,8 @@ extern int icache_44x_need_flush;
*/
#ifdef CONFIG_HIGHMEM
#define KVIRT_TOP PKMAP_BASE
+#elif defined(CONFIG_KASAN)
+#define KVIRT_TOP KASAN_SHADOW_START
#else
#define KVIRT_TOP (0xfe00UL) /* for now, could be FIXMAP_BASE ? */
#endif
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index b5d023680801..80d520e34552 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -251,6 +251,11 @@ GLUE(.,name):
#define _GLOBAL_TOC(name) _GLOBAL(name)
+#define KASAN_OVERRIDE(x, y) \
+ .weak x; \
+ .set x, y
+
+
#endif
/*
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 1fffbba8d6a5..16572484149c 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -67,6 +67,11 @@ void do_barrier_nospec_fixups_range(bool enable, void
*start, void *end);
static inline void do_barrier_nospec_fixups_range(bool enable, void *start,
void *end) { };
#endif
+#ifndef CONFIG_KASAN
+static inline void kasan_early_init(void) { }
+static inline void kasan_init(void) { }
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_SETUP_H */
diff --git a/arch/powerpc/include/asm/string.h
b/arch/powerpc/include/asm/string.h
index 1647de15a31e..28795a72aba1 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -27,6 +27,20 @@ extern int memcmp(const void *,const void *,__kernel_size_t);
extern void * memchr(const void *,int,__kernel_size_t);
extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
+void * __memset(void *, int, __kernel_size_t);
+void * __memcpy(void *, const void *, __kernel_size_t);
+void * __memmove(void *, const void *, __kernel_size_t);
+
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+/*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * should use not instrumented version of mem* functions.
+ */
+#define memcpy(dst, src, len) __memcpy(dst, src, len)
+#define memmove(dst, src, len) __memmove(dst, src, len)
+#define memset(s, c, n) __memset(s, c, n)
+#endif
+
#ifdef CONFIG_PPC64
#define __HAVE_ARCH_MEMSET32
#define __HAVE_ARCH_MEMSET64
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index
[RFC PATCH v2 2/3] powerpc/32: Move early_init() in a separate file
In preparation of KASAN, move early_init() into a separate
file in order to allow deactivation of KASAN for that function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/early_32.c | 35 +++
arch/powerpc/kernel/setup_32.c | 26 --
3 files changed, 36 insertions(+), 27 deletions(-)
create mode 100644 arch/powerpc/kernel/early_32.c
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a5a6a243f3cf..e9a9419b98b6 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -93,7 +93,7 @@ extra-y += vmlinux.lds
obj-$(CONFIG_RELOCATABLE) += reloc_$(BITS).o
-obj-$(CONFIG_PPC32)+= entry_32.o setup_32.o
+obj-$(CONFIG_PPC32)+= entry_32.o setup_32.o early_32.o
obj-$(CONFIG_PPC64)+= dma-iommu.o iommu.o
obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_BOOTX_TEXT) += btext.o
diff --git a/arch/powerpc/kernel/early_32.c b/arch/powerpc/kernel/early_32.c
new file mode 100644
index ..b3e40d6d651c
--- /dev/null
+++ b/arch/powerpc/kernel/early_32.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Early init before relocation
+ */
+
+#include
+#include
+#include
+#include
+
+/*
+ * We're called here very early in the boot.
+ *
+ * Note that the kernel may be running at an address which is different
+ * from the address that it was linked at, so we must use RELOC/PTRRELOC
+ * to access static data (including strings). -- paulus
+ */
+notrace unsigned long __init early_init(unsigned long dt_ptr)
+{
+ unsigned long offset = reloc_offset();
+
+ /* First zero the BSS */
+ memset(PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start);
+
+ /*
+* Identify the CPU type and fix up code sections
+* that depend on which cpu we have.
+*/
+ identify_cpu(offset, mfspr(SPRN_PVR));
+
+ apply_feature_fixups();
+
+ return KERNELBASE + offset;
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 00b8f54fed29..62efe32d890d 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -64,32 +64,6 @@ EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
/*
- * We're called here very early in the boot.
- *
- * Note that the kernel may be running at an address which is different
- * from the address that it was linked at, so we must use RELOC/PTRRELOC
- * to access static data (including strings). -- paulus
- */
-notrace unsigned long __init early_init(unsigned long dt_ptr)
-{
- unsigned long offset = reloc_offset();
-
- /* First zero the BSS */
- memset(PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start);
-
- /*
-* Identify the CPU type and fix up code sections
-* that depend on which cpu we have.
-*/
- identify_cpu(offset, mfspr(SPRN_PVR));
-
- apply_feature_fixups();
-
- return KERNELBASE + offset;
-}
-
-
-/*
* This is run before start_kernel(), the kernel has been relocated
* and we are running with enough of the MMU enabled to have our
* proper kernel virtual addresses
--
2.13.3
Re: [PATCH] hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable.
On 12/19/18 6:07 PM, Greg KH wrote:
On Wed, Dec 19, 2018 at 05:34:32PM +0530, Buland Singh wrote:
On 12/19/18 3:16 PM, Greg KH wrote:
On Wed, Dec 19, 2018 at 02:55:02PM +0530, Buland Singh wrote:
The kernel command parameter 'hpet_mmap' never takes effect due to missing
'=' character in the __setup() code of hpet_mmap_enable and the memory map
of the HPET registers never get expose to userspace.
Signed-off-by: Buland Singh
---
drivers/char/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 4a22b4b41aef..9bffcd37cc7b 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -377,7 +377,7 @@ static __init int hpet_mmap_enable(char *str)
pr_info("HPET mmap %s\n", hpet_mmap_enabled ? "enabled" : "disabled");
return 1;
}
-__setup("hpet_mmap", hpet_mmap_enable);
+__setup("hpet_mmap=", hpet_mmap_enable);
What commit caused this bug? Should this go to the stable kernel trees?
Hello Greg,
The commit id is 3d035f58. The bug is there since the initial patch which
introduced the kernel parameter 'hpet_mmap'. The fix should go to the
stable kernel trees.
Great, can you resend it with all of this information (a fixes: and cc:
stable tag?)
Sure, I will send the v2 with all the information.
Regards,
Buland Singh
linux-next: build warning after merge of the scsi-mkp tree
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/scsi/smartpqi/smartpqi_init.c: In function
'pqi_build_raid_path_request':
drivers/scsi/smartpqi/smartpqi_init.c:478:14: warning: this statement may fall
through [-Wimplicit-fallthrough=]
cdb_length = 0;
~~~^~~
drivers/scsi/smartpqi/smartpqi_init.c:479:2: note: here
case BMIC_IDENTIFY_CONTROLLER:
^~~~
drivers/scsi/smartpqi/smartpqi_init.c:487:14: warning: this statement may fall
through [-Wimplicit-fallthrough=]
cdb_length = 0;
~~~^~~
drivers/scsi/smartpqi/smartpqi_init.c:488:2: note: here
case BMIC_WRITE_HOST_WELLNESS:
^~~~
Introduced by commit
171c28653a2d ("scsi: smartpqi: turn off lun data caching for ptraid")
This due to my use of -Wimplicit-fallthrough for Kees Cook. This is
new code. The warning can be suppressed by adding a comment like
/* fall through */
just above the following "case" or "default" to indicate that the
fallthrough is intended.
--
Cheers,
Stephen Rothwell
pgpK7vxmISiXD.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 0/7] spi: add support for octal mode
Hi, On 20/12/18 11:02 AM, Yogesh Narayan Gaur wrote: [...] >>> Yogesh Gaur (7): >>> spi: add support for octal mode I/O data transfer >>> spi: spi-mem: add support for octal mode I/O data transfer >> >> >> These two patches are already merged and is now part of linux-next[1]. >> Its preferred to send patches based on top of latest linux-next so as to >> avoid >> resending patches that have already been picked up by the maintainer. >> >> [1] >> commit 6b03061f882de49b83ccf44beb3a12c920a2da1b >> Author: Yogesh Narayan Gaur >> Date: Mon Dec 3 08:39:06 2018 + >> >> spi: add support for octal mode I/O data transfer >> >> commit b12a084c8729ef423089bb9a5a143eed39cd94e7 >> Author: Yogesh Narayan Gaur >> Date: Mon Dec 3 08:39:12 2018 + >> >> spi: spi-mem: add support for octal mode I/O data transfer >> >> > I have checked on repo "git://git.infradead.org/linux-mtd.git" on branch > "spi-nor/next" and in that kernel version is 4.20.-rc5. > In this repo above 2 patches are not present and hence has send the patches > by moving to top of this repo. > Those patches are applied to spi tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-next > Can you please let me know the repo of linux-next and branch to use. > The linux-next tree is the holding area for patches aimed at the next kernel merge window. This tree includes spi-nor/next as part of mtd/next as well as many other subsystem specific -next trees: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git branch: master Regards Vignesh > -- > Regards > Yogesh Gaur > >> Regards >> Vignesh >> >>> mtd: spi-nor: add opcodes for octal Read/Write commands >>> mtd: spi-nor: add octal read flag for flash mt35xu512aba >>> mtd: m25p80: add support of octal mode I/O transfer >>> spi: nxp-fspi: add octal mode flag bit for octal support >>> arm64: dts: lx2160a: update fspi node >>> >>> Changes for v6: >>> - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'. >>> - Rebase on top of v4.20-rc5. >>> Changes for v5: >>> - Modified string 'octo' as 'octal' in all patches. >>> Changes for v4: >>> - Rebase on top of v4.20-rc2. >>> - Modify octo entries enum value in spi.h. >>> Changes for v3: >>> - Add octo mode support in spi_setup(). >>> - Rename all patches with 'octal' string modified as 'octo'. >>> Changes for v2: >>> - Incorporated review comments of Boris and Vignesh. >>> >>> Yogesh Gaur (7): >>> spi: add support for octal mode I/O data transfer >>> spi: spi-mem: add support for octal mode I/O data transfer >>> mtd: spi-nor: add opcodes for octal Read/Write commands >>> mtd: spi-nor: add octal read flag for flash mt35xu512aba >>> mtd: m25p80: add support of octal mode I/O transfer >>> spi: nxp-fspi: add octal mode flag bit for octal support >>> arm64: dts: lx2160a: update fspi node >>> >>> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 >>> drivers/mtd/devices/m25p80.c | 9 - >>> drivers/mtd/spi-nor/spi-nor.c | 19 --- >>> drivers/spi/spi-mem.c | 9 - >>> drivers/spi/spi-nxp-fspi.c| 4 ++-- >>> drivers/spi/spi.c | 12 ++-- >>> include/linux/mtd/spi-nor.h | 16 >>> include/linux/spi/spi.h | 4 +++- >>> 8 files changed, 63 insertions(+), 14 deletions(-) >>> >> >> -- >> Regards >> Vignesh
Re: linux-next: manual merge of the char-misc tree with the net-next tree
On Thu, Dec 20, 2018 at 05:02:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/ptp/ptp_clock.c
>
> between commit:
>
> aea0a897af9e ("ptp: Fix pass zero to ERR_PTR() in ptp_clock_register")
>
> from the net-next tree and commit:
>
> b9d93594c767 ("ptp: fix an IS_ERR() vs NULL check")
>
> from the char-misc tree.
>
> I fixed it up (I just used the latter version) 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 merge fix, that is correct.
greg k-h
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 12/20/18 11:50 AM, Alexey Kardashevskiy wrote: On 20/12/2018 16:52, Aneesh Kumar K.V wrote: On 12/20/18 11:18 AM, Alexey Kardashevskiy wrote: On 20/12/2018 16:22, Aneesh Kumar K.V wrote: On 12/20/18 9:49 AM, Alexey Kardashevskiy wrote: On 19/12/2018 14:40, Aneesh Kumar K.V wrote: This helper does a get_user_pages_fast and if it find pages in the CMA area it will try to migrate them before taking page reference. This makes sure that we don't keep non-movable pages (due to page reference count) in the CMA area. Not able to move pages out of CMA area result in CMA allocation failures. Signed-off-by: Aneesh Kumar K.V . + * We did migrate all the pages, Try to get the page references again + * migrating any new CMA pages which we failed to isolate earlier. + */ + drain_allow = true; + goto get_user_again; So it is possible to have pages pinned, then successfully migrated (migrate_pages() returned 0), then pinned again, then some pages may end up in CMA again and migrate again and nothing seems to prevent this loop from being endless. What do I miss? pages used as target page for migration won't be allocated from CMA region. Then migrate_allow should be set to "false" regardless what migrate_pages() returned and then I am totally missing the point of this goto and going through the loop again even when we know for sure it won't do literally anything but checking is_migrate_cma_page() even though we know pages won't be allocated from CMA. Because we might have failed to isolate all the pages in the first attempt. isolate==migrate? no The call to isolate_lru_page and isolate_huge_page. We can fail because the percpu pagevec is not fully drained -aneesh
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 20/12/2018 16:52, Aneesh Kumar K.V wrote: > On 12/20/18 11:18 AM, Alexey Kardashevskiy wrote: >> >> >> On 20/12/2018 16:22, Aneesh Kumar K.V wrote: >>> On 12/20/18 9:49 AM, Alexey Kardashevskiy wrote: On 19/12/2018 14:40, Aneesh Kumar K.V wrote: > This helper does a get_user_pages_fast and if it find pages in the > CMA area > it will try to migrate them before taking page reference. This makes > sure that > we don't keep non-movable pages (due to page reference count) in the > CMA area. > Not able to move pages out of CMA area result in CMA allocation > failures. > > Signed-off-by: Aneesh Kumar K.V >>> >>> . > + * We did migrate all the pages, Try to get the page > references again > + * migrating any new CMA pages which we failed to isolate > earlier. > + */ > + drain_allow = true; > + goto get_user_again; So it is possible to have pages pinned, then successfully migrated (migrate_pages() returned 0), then pinned again, then some pages may end up in CMA again and migrate again and nothing seems to prevent this loop from being endless. What do I miss? >>> >>> pages used as target page for migration won't be allocated from CMA >>> region. >> >> >> Then migrate_allow should be set to "false" regardless what >> migrate_pages() returned and then I am totally missing the point of this >> goto and going through the loop again even when we know for sure it >> won't do literally anything but checking is_migrate_cma_page() even >> though we know pages won't be allocated from CMA. >> > > Because we might have failed to isolate all the pages in the first attempt. isolate==migrate? If we failed to migrate, then migrate_pages() returns non zero (positive or negative), we set migrate_allow to false, empty the cma_page_list and repeat but we won't add anything to cma_page_list as migrate_allow==false. If we succeeded to migrate, then we repeat the loop with migrate_allow==true but it does not matter as is_migrate_cma_page() is expected to return false because we just successfully migrated _everything_ so we won't be adding anything to cma_page_list either. What have I missed? -- Alexey
Re: [PATCH] staging: wilc1000: fix missing read_write setting when reading data
On 12/19/2018 10:00 PM, Colin King wrote:
> From: Colin Ian King
>
> Currently the cmd.read_write setting is not initialized so it contains
> garbage from the stack. Fix this by setting it to 0 to indicate a
> read is required.
>
> Detected by CoverityScan, CID#1357925 ("Uninitialized scalar variable")
>
> Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
Acked-by: Ajay Singh
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/wilc1000/wilc_sdio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/wilc1000/wilc_sdio.c
> b/drivers/staging/wilc1000/wilc_sdio.c
> index 27fdfbdda5c0..e2f739fef21c 100644
> --- a/drivers/staging/wilc1000/wilc_sdio.c
> +++ b/drivers/staging/wilc1000/wilc_sdio.c
> @@ -861,6 +861,7 @@ static int sdio_read_int(struct wilc *wilc, u32
> *int_status)
> if (!sdio_priv->irq_gpio) {
> int i;
>
> + cmd.read_write = 0;
> cmd.function = 1;
> cmd.address = 0x04;
> cmd.data = 0;
>
Re: [PATCH v2] RISC-V: Make BSS section as the last section in vmlinux.lds.S
On Wed, Dec 19, 2018 at 8:37 PM Anup Patel wrote: > > The objcopy only emits loadable sections when creating flat kernel > Image. To have minimal possible size of flat kernel Image, we should > have all non-loadable sections after loadable sections. > > Currently, execption table section (loadable section) is after BSS > section (non-loadable section) in the RISC-V vmlinux.lds.S. This > is not optimal for having minimal flat kernel Image size hence this > patch makes BSS section as the last section in RISC-V vmlinux.lds.S. > > In addition, we make BSS section aligned to 16byte instead of PAGE > aligned which further reduces flat kernel Image size by few KBs. > > The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is > 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to > 7991740 bytes with this patch applied. In summary, this patch reduces > Linux-4.20-rc4 flat kernel Image size by 809 KB. > > Signed-off-by: Anup Patel > --- > > Changes since v1: > - Introduce MAX_BYTES_PER_LONG define and use it in-place of >0x10 magic value > > arch/riscv/kernel/vmlinux.lds.S | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH] KVM: MMU: Introduce single thread to zap collapsible sptes
kindly ping,
On Fri, 14 Dec 2018 at 15:24, Wanpeng Li wrote:
>
> ping,
> On Thu, 6 Dec 2018 at 15:58, Wanpeng Li wrote:
> >
> > From: Wanpeng Li
> >
> > Last year guys from huawei reported that the call of
> > memory_global_dirty_log_start/stop()
> > takes 13s for 4T memory and cause guest freeze too long which increases the
> > unacceptable
> > migration downtime. [1] [2]
> >
> > Guangrong pointed out:
> >
> > | collapsible_sptes zaps 4k mappings to make memory-read happy, it is not
> > | required by the semanteme of KVM_SET_USER_MEMORY_REGION and it is not
> > | urgent for vCPU's running, it could be done in a separate thread and use
> > | lock-break technology.
> >
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05249.html
> > [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg449994.html
> >
> > Several TB memory guest is common now after NVDIMM is deployed in cloud
> > environment.
> > This patch utilizes worker thread to zap collapsible sptes in order to lazy
> > collapse
> > small sptes into large sptes during roll-back after live migration fails.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/include/asm/kvm_host.h | 3 +++
> > arch/x86/kvm/mmu.c | 37 -
> > arch/x86/kvm/x86.c | 4
> > 3 files changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index fbda5a9..dde32f9 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -892,6 +892,8 @@ struct kvm_arch {
> > u64 master_cycle_now;
> > struct delayed_work kvmclock_update_work;
> > struct delayed_work kvmclock_sync_work;
> > + struct delayed_work kvm_mmu_zap_collapsible_sptes_work;
> > + bool zap_in_progress;
> >
> > struct kvm_xen_hvm_config xen_hvm_config;
> >
> > @@ -1247,6 +1249,7 @@ void kvm_mmu_zap_all(struct kvm *kvm);
> > void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm, struct kvm_memslots
> > *slots);
> > unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
> > void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int
> > kvm_nr_mmu_pages);
> > +void zap_collapsible_sptes_fn(struct work_struct *work);
> >
> > int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, unsigned long
> > cr3);
> > bool pdptrs_changed(struct kvm_vcpu *vcpu);
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 7c03c0f..fe87dd3 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -5679,14 +5679,41 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm
> > *kvm,
> > return need_tlb_flush;
> > }
> >
> > +void zap_collapsible_sptes_fn(struct work_struct *work)
> > +{
> > + struct kvm_memory_slot *memslot;
> > + struct kvm_memslots *slots;
> > + struct delayed_work *dwork = to_delayed_work(work);
> > + struct kvm_arch *ka = container_of(dwork, struct kvm_arch,
> > +
> > kvm_mmu_zap_collapsible_sptes_work);
> > + struct kvm *kvm = container_of(ka, struct kvm, arch);
> > + int i;
> > +
> > + mutex_lock(>slots_lock);
> > + for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
> > + spin_lock(>mmu_lock);
> > + slots = __kvm_memslots(kvm, i);
> > + kvm_for_each_memslot(memslot, slots) {
> > + slot_handle_leaf(kvm, (struct kvm_memory_slot
> > *)memslot,
> > + kvm_mmu_zap_collapsible_spte, true);
> > + if (need_resched() ||
> > spin_needbreak(>mmu_lock))
> > + cond_resched_lock(>mmu_lock);
> > + }
> > + spin_unlock(>mmu_lock);
> > + }
> > + kvm->arch.zap_in_progress = false;
> > + mutex_unlock(>slots_lock);
> > +}
> > +
> > +#define KVM_MMU_ZAP_DELAYED (60 * HZ)
> > void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
> >const struct kvm_memory_slot *memslot)
> > {
> > - /* FIXME: const-ify all uses of struct kvm_memory_slot. */
> > - spin_lock(>mmu_lock);
> > - slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
> > -kvm_mmu_zap_collapsible_spte, true);
> > - spin_unlock(>mmu_lock);
> > + if (!kvm->arch.zap_in_progress) {
> > + kvm->arch.zap_in_progress = true;
> > +
> > schedule_delayed_work(>arch.kvm_mmu_zap_collapsible_sptes_work,
> > + KVM_MMU_ZAP_DELAYED);
> > + }
> > }
> >
> > void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index d029377..c2af289 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -9019,6 +9019,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long
> >
[PATCH] mm/page_owner: fix for deferred struct page init
When booting a system with "page_owner=on",
start_kernel
page_ext_init
invoke_init_callbacks
init_section_page_ext
init_page_owner
init_early_allocated_pages
init_zones_in_node
init_pages_in_zone
lookup_page_ext
page_to_nid
The issue here is that page_to_nid() will not work since some page
flags have no node information until later in page_alloc_init_late() due
to DEFERRED_STRUCT_PAGE_INIT. Hence, it could trigger an out-of-bounds
access with an invalid nid.
[8.666047] UBSAN: Undefined behaviour in ./include/linux/mm.h:1104:50
[8.672603] index 7 is out of range for type 'zone [5]'
Also, kernel will panic since flags were poisoned earlier with,
CONFIG_DEBUG_VM_PGFLAGS=y
CONFIG_NODE_NOT_IN_PAGE_FLAGS=n
start_kernel
setup_arch
pagetable_init
paging_init
sparse_init
sparse_init_nid
memblock_alloc_try_nid_raw
Although later it tries to set page flags for pages in reserved bootmem
regions,
mm_init
mem_init
memblock_free_all
free_low_memory_core_early
reserve_bootmem_region
there could still have some freed pages from the page allocator but yet
to be initialized due to DEFERRED_STRUCT_PAGE_INIT. It have already been
dealt with a bit in page_ext_init().
* Take into account DEFERRED_STRUCT_PAGE_INIT.
*/
if (early_pfn_to_nid(pfn) != nid)
continue;
However it did not handle it well in init_pages_in_zone() which end up
calling page_to_nid().
[ 11.917212] page:ea000420 is uninitialized and poisoned
[ 11.917220] raw:
[ 11.921745] raw:
[ 11.924523] page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
[ 11.926498] page_owner info is not active (free page?)
[ 12.329560] kernel BUG at include/linux/mm.h:990!
[ 12.337632] RIP: 0010:init_page_owner+0x486/0x520
Since init_pages_in_zone() has already had the node information, there
is no need to call page_to_nid() at all during the page ext lookup, and
also replace calls that could incorrectly checked for poisoned page
structs.
It ends up wasting some memory to allocate page ext for those already
freed pages, but there is no sane ways to tell those freed pages apart
from uninitialized valid pages due to DEFERRED_STRUCT_PAGE_INIT. It
looks quite reasonable on an arm64 server though.
allocated 83230720 bytes of page_ext
Node 0, zoneDMA32: page owner found early allocated 0 pages
Node 0, zone Normal: page owner found early allocated 2048214 pages
Node 1, zone Normal: page owner found early allocated 2080641 pages
Used more memory on a x86_64 server.
allocated 334233600 bytes of page_ext
Node 0, zone DMA: page owner found early allocated 2 pages
Node 0, zoneDMA32: page owner found early allocated 24303 pages
Node 0, zone Normal: page owner found early allocated 7545357 pages
Node 1, zone Normal: page owner found early allocated 8331279 pages
Finally, rename get_entry() to get_ext_entry(), so it can be exported
without a naming collision.
Signed-off-by: Qian Cai
---
include/linux/page_ext.h | 6 ++
mm/page_ext.c| 8
mm/page_owner.c | 39 ---
3 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index f84f167ec04c..e95cb6198014 100644
--- a/include/linux/page_ext.h
+++ b/include/linux/page_ext.h
@@ -51,6 +51,7 @@ static inline void page_ext_init(void)
#endif
struct page_ext *lookup_page_ext(const struct page *page);
+struct page_ext *get_ext_entry(void *base, unsigned long index);
#else /* !CONFIG_PAGE_EXTENSION */
struct page_ext;
@@ -64,6 +65,11 @@ static inline struct page_ext *lookup_page_ext(const struct
page *page)
return NULL;
}
+static inline struct page_ext *get_ext_entry(void *base, unsigned long index)
+{
+ return NULL;
+}
+
static inline void page_ext_init(void)
{
}
diff --git a/mm/page_ext.c b/mm/page_ext.c
index ae44f7adbe07..3cd8f0c13057 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -107,7 +107,7 @@ static unsigned long get_entry_size(void)
return sizeof(struct page_ext) + extra_mem;
}
-static inline struct page_ext *get_entry(void *base, unsigned long index)
+struct page_ext *get_ext_entry(void *base, unsigned long index)
{
return base + get_entry_size() * index;
}
@@ -137,7 +137,7 @@ struct page_ext *lookup_page_ext(const struct page *page)
return NULL;
index = pfn - round_down(node_start_pfn(page_to_nid(page)),
MAX_ORDER_NR_PAGES);
- return get_entry(base, index);
+ return get_ext_entry(base, index);
}
static int __init alloc_node_page_ext(int nid)
@@ -207,7 +207,7 @@ struct page_ext *lookup_page_ext(const struct page *page)
*/
linux-next: manual merge of the char-misc tree with the net-next tree
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/ptp/ptp_clock.c
between commit:
aea0a897af9e ("ptp: Fix pass zero to ERR_PTR() in ptp_clock_register")
from the net-next tree and commit:
b9d93594c767 ("ptp: fix an IS_ERR() vs NULL check")
from the char-misc tree.
I fixed it up (I just used the latter version) 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
pgpGQDFR_Mltk.pgp
Description: OpenPGP digital signature
RE: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
Hi Bjorn:
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2018年12月19日 23:52
> To: Bjorn Helgaas ; Richard Zhu
>
> Cc: Lorenzo Pieralisi ; Andrew Smirnov
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Sven Van
> Asbroeck ; Niklas Cassel ;
> Kishon Vijay Abraham I ; Gustavo Pimentel
> ; Shawn Lin ;
> Trent Piepho
> Subject: Re: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
>
> Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> > [+cc Sven, Trent, et al from related report:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >
> e.kernel.org%2Flinux-pci%2F20181218210444.5950-1-TheSven73%40google
> mai
> >
> l.comdata=02%7C01%7Chongxing.zhu%40nxp.com%7C05ba3b5bb42c
> 4db9bf3b
> >
> 08d665c9f17b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 808315347
> >
> 780466sdata=ta7ffj9EPGoqAjDiS1ORvR65A2IhMUpb2Endz9%2B6zM4
> %3D
> > reserved=0]
> >
> > On Fri, Dec 14, 2018 at 06:44:15AM +, Richard Zhu wrote:
> > > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory
> > > required to trigger MSI on i.MX6 PCIe.
> > > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > >
> > > Assert it unconditionally when MSI is enabled.
> > > Otherwise, the MSI wouldn't be triggered although the EP is present
> > > and the MSIs are assigned.
> >
> > OK, I think I finally understand most of what's going on. Please
> > check the following possible changelog text:
> >
> > The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> > controls whether a Function can request service using MSI.
> >
> > i.MX6 Root Ports implement the MSI Capability and may use MSI to
> > request service for events like PME, hotplug, AER, etc. In
> > addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> > interrupts from components below the Root Port.
> >
> > Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically
> also
> > enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root
> Ports,
> > it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> > As a side effect, that also enabled delivery of MSI interrupts from
> > downstream components.
> >
> > After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> > portdrv, but that means imx6q-pcie must set the MSI Enable bit
> > itself if downstream components use MSI.
> >
> > Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS")
> >
> > I still don't understand exactly *how* MSI Enable affects MSI from
> > downstream components, since the downstream component just does a
> DMA
> > write, and the Root Port can't tell whether the write is to memory or
> > interrupt controller unless the Root Port knows where the MSI targets
> > are, e.g., if the interrupt controller is actually part of the RC.
>
[Richard Zhu] Thanks a lot for your kindly help to craft the commit log.
I'm totally fine with it.
Just like Lucas said below, the MSI trigger conditions are part of the glue
logic
When integrate this IP into iMX6 SOC.
The MSI Enable bit set of RC is one of the mandatory required condition to
trigger MSI from EP.
Best Regards
Richard Zhu
> The controller terminating the MSI write is part of the DWC PCIe host
> controller on i.MX6, which is questionable at least when you think about how
> a MSI should be self-synchronizing to memory writes, but that's reality...
>
> As to why the controller needs the MSI Enable bit set, I have no idea.
> But then the DWC controller is known to have some funky design limitations
> regarding MSI, like not forwarding legacy PCI interrupts anymore when MSI is
> enabled, so it's not totally surprising that we need some quirky setup here.
>
> Regards,
> Lucas
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 12/20/18 11:18 AM, Alexey Kardashevskiy wrote: On 20/12/2018 16:22, Aneesh Kumar K.V wrote: On 12/20/18 9:49 AM, Alexey Kardashevskiy wrote: On 19/12/2018 14:40, Aneesh Kumar K.V wrote: This helper does a get_user_pages_fast and if it find pages in the CMA area it will try to migrate them before taking page reference. This makes sure that we don't keep non-movable pages (due to page reference count) in the CMA area. Not able to move pages out of CMA area result in CMA allocation failures. Signed-off-by: Aneesh Kumar K.V . + * We did migrate all the pages, Try to get the page references again + * migrating any new CMA pages which we failed to isolate earlier. + */ + drain_allow = true; + goto get_user_again; So it is possible to have pages pinned, then successfully migrated (migrate_pages() returned 0), then pinned again, then some pages may end up in CMA again and migrate again and nothing seems to prevent this loop from being endless. What do I miss? pages used as target page for migration won't be allocated from CMA region. Then migrate_allow should be set to "false" regardless what migrate_pages() returned and then I am totally missing the point of this goto and going through the loop again even when we know for sure it won't do literally anything but checking is_migrate_cma_page() even though we know pages won't be allocated from CMA. Because we might have failed to isolate all the pages in the first attempt. -aneesh
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 20/12/2018 16:22, Aneesh Kumar K.V wrote: > On 12/20/18 9:49 AM, Alexey Kardashevskiy wrote: >> >> >> On 19/12/2018 14:40, Aneesh Kumar K.V wrote: >>> This helper does a get_user_pages_fast and if it find pages in the >>> CMA area >>> it will try to migrate them before taking page reference. This makes >>> sure that >>> we don't keep non-movable pages (due to page reference count) in the >>> CMA area. >>> Not able to move pages out of CMA area result in CMA allocation >>> failures. >>> >>> Signed-off-by: Aneesh Kumar K.V >> > > . >>> + * We did migrate all the pages, Try to get the page >>> references again >>> + * migrating any new CMA pages which we failed to isolate >>> earlier. >>> + */ >>> + drain_allow = true; >>> + goto get_user_again; >> >> >> So it is possible to have pages pinned, then successfully migrated >> (migrate_pages() returned 0), then pinned again, then some pages may end >> up in CMA again and migrate again and nothing seems to prevent this loop >> from being endless. What do I miss? >> > > pages used as target page for migration won't be allocated from CMA region. Then migrate_allow should be set to "false" regardless what migrate_pages() returned and then I am totally missing the point of this goto and going through the loop again even when we know for sure it won't do literally anything but checking is_migrate_cma_page() even though we know pages won't be allocated from CMA. It should be simple gup_fast() instead of goto and then we won't need goto/migrate_allow. -- Alexey
[PATCH] powerpc/8xx: Map a second 8M text page at startup when needed.
Some debug setup like CONFIG_KASAN generate huge
kernels with text size over the 8M limit.
This patch maps a second 8M page when _einittext is over 8M.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 27 +--
arch/powerpc/mm/8xx_mmu.c | 4
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index b171b7c0a0e7..f6bc4392ea9f 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -334,8 +334,8 @@ InstructionTLBMiss:
rlwinm r10, r10, 16, 0xfff8
cmpli cr0, r10, PAGE_OFFSET@h
#ifndef CONFIG_PIN_TLB_TEXT
- /* It is assumed that kernel code fits into the first 8M page */
-0: cmpli cr7, r10, (PAGE_OFFSET + 0x080)@h
+ /* It is assumed that kernel code fits into the two first 8M pages */
+0: cmpli cr7, r10, (PAGE_OFFSET + 0x100)@h
patch_site 0b, patch__itlbmiss_linmem_top
#endif
#endif
@@ -904,6 +904,29 @@ initial_mmu:
li r8, MI_BOOTINIT /* Create RPN for address 0 */
mtspr SPRN_MI_RPN, r8 /* Store TLB entry */
+ /* Map a second 8M page if needed */
+ lis r9, _einittext@h
+ orisr9, r9, _einittext@l
+ cmpli cr0, r9, (PAGE_OFFSET + 0x800)@h
+ blt 1f
+
+#ifdef CONFIG_PIN_TLB_TEXT
+ lis r8, MI_RSV4I@h
+ ori r8, r8, 0x1d00
+
+ mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */
+#endif
+
+ lis r8, (KERNELBASE + 0x80)@h /* Create vaddr for TLB */
+ ori r8, r8, MI_EVALID /* Mark it valid */
+ mtspr SPRN_MI_EPN, r8
+ li r8, MI_PS8MEG /* Set 8M byte page */
+ ori r8, r8, MI_SVALID /* Make it valid */
+ mtspr SPRN_MI_TWC, r8
+ li r8, MI_BOOTINIT /* Create RPN for address 0 */
+ addis r8, r8, 0x80
+ mtspr SPRN_MI_RPN, r8 /* Store TLB entry */
+1:
lis r8, MI_APG_INIT@h /* Set protection modes */
ori r8, r8, MI_APG_INIT@l
mtspr SPRN_MI_AP, r8
diff --git a/arch/powerpc/mm/8xx_mmu.c b/arch/powerpc/mm/8xx_mmu.c
index e2b6687ebb50..1bdbfbf9fe16 100644
--- a/arch/powerpc/mm/8xx_mmu.c
+++ b/arch/powerpc/mm/8xx_mmu.c
@@ -122,6 +122,10 @@ unsigned long __init mmu_mapin_ram(unsigned long top)
#endif
} else {
mapped = top & ~(LARGE_PAGE_SIZE_8M - 1);
+#ifndef CONFIG_PIN_TLB_TEXT
+ mmu_patch_cmp_limit(__itlbmiss_linmem_top,
+ _ALIGN(__pa(_einittext), 8 << 20));
+#endif
}
mmu_patch_cmp_limit(__dtlbmiss_linmem_top, mapped);
--
2.13.3
[PATCH 1/2 v4] kdump: add the vmcoreinfo documentation
This document lists some variables that export to vmcoreinfo, and briefly describles what these variables indicate. It should be instructive for many people who do not know the vmcoreinfo, and it also normalizes the exported variables as a convention between kernel and use-space. Suggested-by: Borislav Petkov Signed-off-by: Lianbo Jiang --- Documentation/kdump/vmcoreinfo.txt | 513 + 1 file changed, 513 insertions(+) create mode 100644 Documentation/kdump/vmcoreinfo.txt diff --git a/Documentation/kdump/vmcoreinfo.txt b/Documentation/kdump/vmcoreinfo.txt new file mode 100644 index ..1f1f69143600 --- /dev/null +++ b/Documentation/kdump/vmcoreinfo.txt @@ -0,0 +1,513 @@ + + VMCOREINFO + + +=== +What is the VMCOREINFO? +=== + +VMCOREINFO is a special ELF note section. It contains various +information from the kernel like structure size, page size, symbol +values, field offsets, etc. These data are packed into an ELF note +section and used by user-space tools like crash and makedumpfile to +analyze a kernel's memory layout. + +To dump the VMCOREINFO contents, one can do: + +# makedumpfile -g VMCOREINFO -x vmlinux + + +Common variables + + +init_uts_ns.name.release + + +The version of the Linux kernel. Used to find the corresponding source +code from which the kernel has been built. + +PAGE_SIZE +- + +The size of a page. It is the smallest unit of data for memory +management in kernel. It is usually 4096 bytes and a page is aligned on +4096 bytes. Used for computing page addresses. + +init_uts_ns +--- + +This is the UTS namespace, which is used to isolate two specific +elements of the system that relate to the uname(2) system call. The UTS +namespace is named after the data structure used to store information +returned by the uname(2) system call. + +User-space tools can get the kernel name, host name, kernel release +number, kernel version, architecture name and OS type from it. + +node_online_map +--- + +An array node_states[N_ONLINE] which represents the set of online node +in a system, one bit position per node number. Used to keep track of +which nodes are in the system and online. + +swapper_pg_dir +- + +The global page directory pointer of the kernel. Used to translate +virtual to physical addresses. + +_stext +-- + +Defines the beginning of the text section. In general, _stext indicates +the kernel start address. Used to convert a virtual address from the +direct kernel map to a physical address. + +vmap_area_list +-- + +Stores the virtual area list. makedumpfile can get the vmalloc start +value from this variable. This value is necessary for vmalloc translation. + +mem_map +--- + +Physical addresses are translated to struct pages by treating them as +an index into the mem_map array. Right-shifting a physical address +PAGE_SHIFT bits converts it into a page frame number which is an index +into that mem_map array. + +Used to map an address to the corresponding struct page. + +contig_page_data + + +Makedumpfile can get the pglist_data structure from this symbol, which +is used to describe the memory layout. + +User-space tools use this to exclude free pages when dumping memory. + +mem_section|(mem_section, NR_SECTION_ROOTS)|(mem_section, section_mem_map) +-- + +The address of the mem_section array, its length, structure size, and +the section_mem_map offset. + +It exists in the sparse memory mapping model, and it is also somewhat +similar to the mem_map variable, both of them are used to translate an +address. + +page + + +The size of a page structure. struct page is an important data structure +and it is widely used to compute the contiguous memory. + +pglist_data +--- + +The size of a pglist_data structure. This value will be used to check +if the pglist_data structure is valid. It is also used for checking the +memory type. + +zone + + +The size of a zone structure. This value is often used to check if the +zone structure has been found. It is also used for excluding free pages. + +free_area +- + +The size of a free_area structure. It indicates whether the free_area +structure is valid or not. Useful for excluding free pages. + +list_head +- + +The size of a list_head structure. Used when iterating lists in a +post-mortem analysis session. + +nodemask_t +-- + +The size of a nodemask_t type. Used to compute the number of online +nodes. + +(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor| + compound_order|compound_head) +--- + +User-space tools
[PATCH 2/2 v4] kdump,vmcoreinfo: Export the value of sme mask to vmcoreinfo
For AMD machine with SME feature, makedumpfile tools need to know
whether the crash kernel was encrypted or not. If SME is enabled
in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
contains the memory encryption mask, so need to remove the sme mask
to obtain the true physical address.
Signed-off-by: Lianbo Jiang
---
arch/x86/kernel/machine_kexec_64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 4c8acdfdc5a7..bc4108096b18 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -352,10 +352,13 @@ void machine_kexec(struct kimage *image)
void arch_crash_save_vmcoreinfo(void)
{
+ u64 sme_mask = sme_me_mask;
+
VMCOREINFO_NUMBER(phys_base);
VMCOREINFO_SYMBOL(init_top_pgt);
vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
pgtable_l5_enabled());
+ VMCOREINFO_NUMBER(sme_mask);
#ifdef CONFIG_NUMA
VMCOREINFO_SYMBOL(node_data);
--
2.17.1
[PATCH 0/2 v4] kdump,vmcoreinfo: Export the value of sme mask to vmcoreinfo
This patchset did two things: a. add a new document for vmcoreinfo This document lists some variables that export to vmcoreinfo, and briefly describles what these variables indicate. It should be instructive for many people who do not know the vmcoreinfo, and it also normalizes the exported variable as a convention between kernel and use-space. b. export the value of sme mask to vmcoreinfo For AMD machine with SME feature, makedumpfile tools need to know whether the crash kernel was encrypted or not. If SME is enabled in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte) contains the memory encryption mask, so need to remove the sme mask to obtain the true physical address. Changes since v1: 1. No need to export a kernel-internal mask to userspace, so copy the value of sme_me_mask to a local variable 'sme_mask' and write the value of sme_mask to vmcoreinfo. 2. Add comment for the code. 3. Improve the patch log. 4. Add the vmcoreinfo documentation. Changes since v2: 1. Improve the vmcoreinfo document, add more descripts for these variables exported. 2. Fix spelling errors in the document. Changes since v3: 1. Still improve the vmcoreinfo document, and make it become more clear and easy to read. 2. Move sme_mask comments in the code to the vmcoreinfo document. 3. Improve patch log. Lianbo Jiang (2): kdump: add the vmcoreinfo documentation kdump,vmcoreinfo: Export the value of sme mask to vmcoreinfo Documentation/kdump/vmcoreinfo.txt | 513 + arch/x86/kernel/machine_kexec_64.c | 3 + 2 files changed, 516 insertions(+) create mode 100644 Documentation/kdump/vmcoreinfo.txt -- 2.17.1
RE: [PATCH v6 0/7] spi: add support for octal mode
Hi Vignesh, > -Original Message- > From: Vignesh R [mailto:vigne...@ti.com] > Sent: Wednesday, December 19, 2018 6:14 PM > To: Yogesh Narayan Gaur ; linux- > m...@lists.infradead.org; boris.brezil...@bootlin.com; broo...@kernel.org; > marek.va...@gmail.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org > Cc: tudor.amba...@microchip.com; r...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; linux-arm-ker...@lists.infradead.org; > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v6 0/7] spi: add support for octal mode > > Hi, > > On 19/12/18 3:41 PM, Yogesh Narayan Gaur wrote: > > Add support for octal mode IO data transfer. > > Micron flash, mt35xu512aba, supports octal mode data transfer and NXP > > FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > > > Patch series > > * Add support for octal mode flags and parsing of same in spi driver. > > * Add parsing logic for spi-mem framework and m25p80.c device file. > > * Add opcodes for octal I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > > Opcodes are added as per octal data IO commands required for > mt35xu512aba [1] flash. > > * Add mode bit required for octal mode in nxp-fspi driver [2]. > > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > > > > Tested on LX2160ARDB target with nxp-fspi driver, below are Read > > performance number of 1-1-1 and 1-1-8 read protocol. > > > > root@lxxx:~# cat /proc/mtd > > dev:size erasesize name > > mtd0: 0400 1000 "spi0.0" > > mtd1: 0400 1000 "spi0.1" > > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > > Copied 16777216 bytes from address 0x in flash to 0read > > > > real0m2.792s > > user0m0.000s > > sys 0m2.790s > > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > > Copied 16777216 bytes from address 0x in flash to 0read > > > > real0m0.441s > > user0m0.000s > > sys 0m0.440s > > root@ls1012ardb:~# > > > > > > Flash device MTD0 configured in 1-1-1 protocol. > > Flash device MTD1 configured in 1-1-8 protocol. > > > > [1] > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > > chwork.ozlabs.org%2Fproject%2Flinux- > mtd%2Flist%2F%3Fseries%3D70384%26s > > > tate%3D*data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Cac5c9 > ca4ad0 > > > 84f10762208d665af9130%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C636 > > > 808202064181032sdata=LCjo%2B%2FhIpEYygsLHMFzb65ZtXjsDdhEAVV4 > %2BjQ > > iyUtI%3Dreserved=0 [2] > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > > chwork.ozlabs.org%2Fproject%2Flinux- > mtd%2Flist%2F%3Fseries%3D76402 > > ;data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Cac5c9ca4ad084f107 > 62208d > > > 665af9130%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636808202 > 064181 > > > 032sdata=A9hAX4oTyJPzc4J3y3PqwNagWEqvpGolf8RE9RyYV28%3D > p;reser > > ved=0 > > > > Yogesh Gaur (7): > > spi: add support for octal mode I/O data transfer > > spi: spi-mem: add support for octal mode I/O data transfer > > > These two patches are already merged and is now part of linux-next[1]. > Its preferred to send patches based on top of latest linux-next so as to avoid > resending patches that have already been picked up by the maintainer. > > [1] > commit 6b03061f882de49b83ccf44beb3a12c920a2da1b > Author: Yogesh Narayan Gaur > Date: Mon Dec 3 08:39:06 2018 + > > spi: add support for octal mode I/O data transfer > > commit b12a084c8729ef423089bb9a5a143eed39cd94e7 > Author: Yogesh Narayan Gaur > Date: Mon Dec 3 08:39:12 2018 + > > spi: spi-mem: add support for octal mode I/O data transfer > > I have checked on repo "git://git.infradead.org/linux-mtd.git" on branch "spi-nor/next" and in that kernel version is 4.20.-rc5. In this repo above 2 patches are not present and hence has send the patches by moving to top of this repo. Can you please let me know the repo of linux-next and branch to use. -- Regards Yogesh Gaur > Regards > Vignesh > > > mtd: spi-nor: add opcodes for octal Read/Write commands > > mtd: spi-nor: add octal read flag for flash mt35xu512aba > > mtd: m25p80: add support of octal mode I/O transfer > > spi: nxp-fspi: add octal mode flag bit for octal support > > arm64: dts: lx2160a: update fspi node > > > > Changes for v6: > > - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'. > > - Rebase on top of v4.20-rc5. > > Changes for v5: > > - Modified string 'octo' as 'octal' in all patches. > > Changes for v4: > > - Rebase on top of v4.20-rc2. > > - Modify octo entries enum value in spi.h. > > Changes for v3: > > - Add octo mode support in spi_setup(). > > - Rename all patches with 'octal' string modified as 'octo'. > > Changes for v2: > > - Incorporated review comments of Boris and Vignesh. > > > > Yogesh Gaur (7): > > spi: add support for
Re: Taking a break - time to look back
Hi Thomas, [trimmed cc list] On Thu, Dec 20, 2018 at 01:46:24AM +0100, Thomas Gleixner wrote: > 1) Lack of code quality > > This is a problem which I observe increasing over many years. > > The feature driven duct tape engineering mode is progressing > massively. Proper root cause analysis has become the exception not the > rule. > > In our normal kernel development it's just annoying and eats up review > capacity unnecessarily, but in the face of a timeline or real bugs it's > worse. Aside of wasting time for review rounds, at some point other > people have to just drop everything else and get it fixed. > > Even if some people don't want to admit it, the increasing complexity > of the hardware technology and as a consequence the increasing > complexity of the kernel code base makes it mandatory to put > correctness and maintainability first and not to fall for the > featuritis and performance chants which are driving this > industry. We've learned painfully what that causes in the last year. I totally agree on this point by having been hit by the same problem on another project (haproxy). It turns out that everyone are interested in features, reliability and performance. But these ones cannot come without maintainability, and in practice only these 3 former ones can improve over time. Maintainability only gets worse and is never ever addressed "later" by incremental code updates. Now I tend to be a bastard on this point and to demand properly documented patches, properly named functions/variables and everything that helps other people quickly figure why the code works or doesn't work, knowing that performance/features/reliability area easily addressed afterwards by many other contributors when the code is maintainable. > That said, I'm going to vanish into vacation until Jan. 7th and I'm not > going to read any (LKML) mails until then. As I predict from experience > that my (filtered) inbox will be a untameable beast by then, don't expect > me to actually go through it mail by mail. If your mail will unfortunately > end up in the 'lkml/done' folder without being read, I'm sure you'll notice > and find a way to resend it. Take your well deserved vacation with your family, ignore e-mails and don't read the news, it will only make you relax better, and you'll come back fully recharged. Willy
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 12/20/18 9:49 AM, Alexey Kardashevskiy wrote: On 19/12/2018 14:40, Aneesh Kumar K.V wrote: This helper does a get_user_pages_fast and if it find pages in the CMA area it will try to migrate them before taking page reference. This makes sure that we don't keep non-movable pages (due to page reference count) in the CMA area. Not able to move pages out of CMA area result in CMA allocation failures. Signed-off-by: Aneesh Kumar K.V . +* We did migrate all the pages, Try to get the page references again +* migrating any new CMA pages which we failed to isolate earlier. +*/ + drain_allow = true; + goto get_user_again; So it is possible to have pages pinned, then successfully migrated (migrate_pages() returned 0), then pinned again, then some pages may end up in CMA again and migrate again and nothing seems to prevent this loop from being endless. What do I miss? pages used as target page for migration won't be allocated from CMA region. -aneesh
Re: [PATCH V5 2/3] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get
On 19/12/2018 14:40, Aneesh Kumar K.V wrote:
> Current code doesn't do page migration if the page allocated is a compound
> page.
> With HugeTLB migration support, we can end up allocating hugetlb pages from
> CMA region. Also THP pages can be allocated from CMA region. This patch
> updates
> the code to handle compound pages correctly.
>
> This use the new helper get_user_pages_cma_migrate. It does one get_user_pages
> with right count, instead of doing one get_user_pages per page. That avoids
> reading page table multiple times.
>
> The patch also convert the hpas member of mm_iommu_table_group_mem_t to a
> union.
> We use the same storage location to store pointers to struct page. We cannot
> update alll the code path use struct page *, because we access hpas in real
> mode
s/alll/all/
> and we can't do that struct page * to pfn conversion in real mode.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/mm/mmu_context_iommu.c | 120
> 1 file changed, 35 insertions(+), 85 deletions(-)
>
> diff --git a/arch/powerpc/mm/mmu_context_iommu.c
> b/arch/powerpc/mm/mmu_context_iommu.c
> index 56c2234cc6ae..1d5161f93ce6 100644
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> static DEFINE_MUTEX(mem_list_mutex);
>
> @@ -34,8 +35,18 @@ struct mm_iommu_table_group_mem_t {
> atomic64_t mapped;
> unsigned int pageshift;
> u64 ua; /* userspace address */
> - u64 entries;/* number of entries in hpas[] */
Still a valid comment imho, or you could s'hpas'hpas/hpages' but
replacing hpas with hpages seems strange.
> - u64 *hpas; /* vmalloc'ed */
> + u64 entries;/* number of entries in hpages[] */
> + /*
> + * in mm_iommu_get we temporarily use this to store
> + * struct page address.
> + *
> + * We need to convert ua to hpa in real mode. Make it
> + * simpler by storing physicall address.
s/physicall/physical/
> + */
> + union {
> + struct page **hpages; /* vmalloc'ed */
> + phys_addr_t *hpas;
> + };
> };
>
> static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
> @@ -78,63 +89,14 @@ bool mm_iommu_preregistered(struct mm_struct *mm)
> }
> EXPORT_SYMBOL_GPL(mm_iommu_preregistered);
>
> -/*
> - * Taken from alloc_migrate_target with changes to remove CMA allocations
> - */
> -struct page *new_iommu_non_cma_page(struct page *page, unsigned long private)
> -{
> - gfp_t gfp_mask = GFP_USER;
> - struct page *new_page;
> -
> - if (PageCompound(page))
> - return NULL;
> -
> - if (PageHighMem(page))
> - gfp_mask |= __GFP_HIGHMEM;
> -
> - /*
> - * We don't want the allocation to force an OOM if possibe
> - */
> - new_page = alloc_page(gfp_mask | __GFP_NORETRY | __GFP_NOWARN);
> - return new_page;
> -}
> -
> -static int mm_iommu_move_page_from_cma(struct page *page)
> -{
> - int ret = 0;
> - LIST_HEAD(cma_migrate_pages);
> -
> - /* Ignore huge pages for now */
> - if (PageCompound(page))
> - return -EBUSY;
> -
> - lru_add_drain();
> - ret = isolate_lru_page(page);
> - if (ret)
> - return ret;
> -
> - list_add(>lru, _migrate_pages);
> - put_page(page); /* Drop the gup reference */
> -
> - ret = migrate_pages(_migrate_pages, new_iommu_non_cma_page,
> - NULL, 0, MIGRATE_SYNC, MR_CONTIG_RANGE);
> - if (ret) {
> - if (!list_empty(_migrate_pages))
> - putback_movable_pages(_migrate_pages);
> - }
> -
> - return 0;
> -}
> -
> long mm_iommu_get(struct mm_struct *mm, unsigned long ua, unsigned long
> entries,
> struct mm_iommu_table_group_mem_t **pmem)
> {
> struct mm_iommu_table_group_mem_t *mem;
> - long i, j, ret = 0, locked_entries = 0;
> + long i, ret = 0, locked_entries = 0;
> unsigned int pageshift;
> unsigned long flags;
> unsigned long cur_ua;
> - struct page *page = NULL;
>
> mutex_lock(_list_mutex);
>
> @@ -181,41 +143,24 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long
> ua, unsigned long entries,
> goto unlock_exit;
> }
>
> + ret = get_user_pages_cma_migrate(ua, entries, 1, mem->hpages);
btw get_user_pages_cma_migrate() name suggests me (yeah, not a native
speaker and an ignorant person in general :) ) that it migrates and pins
pages while it can actually pin pages without migrating them (if it
could not).
> + if (ret != entries) {
> + /* free the reference taken */
> + for (i = 0; i < ret; i++)
> + put_page(mem->hpages[i]);
> +
> + vfree(mem->hpas);
> + kfree(mem);
> + ret = -EFAULT;
> + goto unlock_exit;
>
RE: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
Hi Bjorn:
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2018年12月19日 23:52
> To: Bjorn Helgaas ; Richard Zhu
>
> Cc: Lorenzo Pieralisi ; Andrew Smirnov
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Sven Van
> Asbroeck ; Niklas Cassel ;
> Kishon Vijay Abraham I ; Gustavo Pimentel
> ; Shawn Lin ;
> Trent Piepho
> Subject: Re: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
>
> Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> > [+cc Sven, Trent, et al from related report:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >
> e.kernel.org%2Flinux-pci%2F20181218210444.5950-1-TheSven73%40google
> mai
> >
> l.comdata=02%7C01%7Chongxing.zhu%40nxp.com%7C05ba3b5bb42c
> 4db9bf3b
> >
> 08d665c9f17b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 808315347
> >
> 780466sdata=ta7ffj9EPGoqAjDiS1ORvR65A2IhMUpb2Endz9%2B6zM4
> %3D
> > reserved=0]
> >
> > On Fri, Dec 14, 2018 at 06:44:15AM +, Richard Zhu wrote:
> > > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory
> > > required to trigger MSI on i.MX6 PCIe.
> > > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > >
> > > Assert it unconditionally when MSI is enabled.
> > > Otherwise, the MSI wouldn't be triggered although the EP is present
> > > and the MSIs are assigned.
> >
> > OK, I think I finally understand most of what's going on. Please
> > check the following possible changelog text:
> >
> > The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> > controls whether a Function can request service using MSI.
> >
> > i.MX6 Root Ports implement the MSI Capability and may use MSI to
> > request service for events like PME, hotplug, AER, etc. In
> > addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> > interrupts from components below the Root Port.
> >
> > Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically
> also
> > enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root
> Ports,
> > it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> > As a side effect, that also enabled delivery of MSI interrupts from
> > downstream components.
> >
> > After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> > portdrv, but that means imx6q-pcie must set the MSI Enable bit
> > itself if downstream components use MSI.
> >
> > Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS")
> >
> > I still don't understand exactly *how* MSI Enable affects MSI from
> > downstream components, since the downstream component just does a
> DMA
> > write, and the Root Port can't tell whether the write is to memory or
> > interrupt controller unless the Root Port knows where the MSI targets
> > are, e.g., if the interrupt controller is actually part of the RC.
>
[Richard Zhu] Thanks a lot for your kindly help to craft the commit log.
I'm totally fine with it.
Just like Lucas said below, the MSI trigger conditions are part of the glue
logic
When integrate this IP into iMX6 SOC.
The MSI Enable bit set of RC is one of the mandatory required condition to
trigger MSI from EP.
Best Regards
Richard Zhu
> The controller terminating the MSI write is part of the DWC PCIe host
> controller on i.MX6, which is questionable at least when you think about how
> a MSI should be self-synchronizing to memory writes, but that's reality...
>
> As to why the controller needs the MSI Enable bit set, I have no idea.
> But then the DWC controller is known to have some funky design limitations
> regarding MSI, like not forwarding legacy PCI interrupts anymore when MSI is
> enabled, so it's not totally surprising that we need some quirky setup here.
>
> Regards,
> Lucas
linux-next: please clean up the clockevents tree
Hi Daniel, It looks like all the changes in the clockevents tree appear as other commits in other tree(s). Could you please reset your tree to somewhere in your upstream tree as it is beginning to produce conflicts. -- Cheers, Stephen Rothwell pgpBNGIoL6Ql8.pgp Description: OpenPGP digital signature
[GIT] Networking
This should be the last networking pull request before the next merge window. 1) Off by one in netlink parsing of mac802154_hwsim, from Alexander Aring. 2) nf_tables RCU usage fix from Taehee Yoo. 3) Flow dissector needs nhoff and thoff clamping, from Stanislav Fomichev. 4) Missing sin6_flowinfo initialization in SCTP, from Xin Long. 5) Spectrev1 in ipmr and ip6mr, from Gustavo A. R. Silva. 6) Fix r8169 crash when DEBUG_SHIRQ is enabled, from Heiner Kallweit. 7) Fix SKB leak in rtlwifi, from Larry Finger. 8) Fix state pruning in bpf verifier, from Jakub Kicinski. 9) Don't handle completely duplicate fragments as overlapping, from Michal Kubecek. 10) Fix memory corruption with macb and 64-bit DMA, from Anssi Hannula. 11) Fix TCP fallback socket release in smc, from Myungho Jung. 12) gro_cells_destroy needs to napi_disable, from Lorenzo Bianconi. Please pull, thanks a lot! The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d: Linux 4.20-rc6 (2018-12-09 15:31:00 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net for you to fetch changes up to d84e7bc0595a7e146ad0ddb80b240cea77825245: rds: Fix warning. (2018-12-19 20:53:18 -0800) Alaa Hleihel (1): net/mlx5e: Remove the false indication of software timestamping support Alexander Aring (1): ieee802154: hwsim: fix off-by-one in parse nested Anssi Hannula (3): net: macb: fix random memory corruption on RX with 64-bit DMA net: macb: fix dropped RX frames due to a race net: macb: add missing barriers when reading descriptors Antoine Tenart (2): net: mvpp2: 10G modes aren't supported on all ports net: mvpp2: fix the phylink mode validation Arnd Bergmann (1): w90p910_ether: remove incorrect __init annotation Atul Gupta (5): net/tls: Init routines in create_ctx net/tls: sleeping function from invalid context crypto/chelsio/chtls: listen fails with multiadapt crypto/chelsio/chtls: macro correction in tx path crypto/chelsio/chtls: send/recv window update Benjamin Poirier (1): xfrm: Fix bucket count reported to userspace Brian Norris (1): Revert "mwifiex: restructure rx_reorder_tbl_lock usage" Bryan Whitehead (2): lan743x: Expand phy search for LAN7431 lan743x: Remove MAC Reset from initialization Claudiu Beznea (1): net: macb: restart tx after tx used bit read Colin Ian King (1): vxge: ensure data0 is initialized in when fetching firmware version information Cong Wang (6): tipc: use lock_sock() in tipc_sk_reinit() tipc: fix a double kfree_skb() tipc: compare remote and local protocols in tipc_udp_enable() tipc: check tsk->group in tipc_wait_for_cond() tipc: check group dests after tipc_wait_for_cond() ipv6: explicitly initialize udp6_addr in udp_sock_create6() Dan Carpenter (2): qed: Fix an error code qed_ll2_start_xmit() net: stmmac: Fix an error code in probe() Daniel Borkmann (1): bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K Dave Taht (1): net: Allow class-e address assignment via ifconfig ioctl David Ahern (1): neighbor: NTF_PROXY is a valid ndm_flag for a dump request David S. Miller (20): Merge branch 'ibmvnic-Fix-reset-work-item-locking-bugs' Merge branch 'ieee802154-for-davem-2018-12-11' of git://git.kernel.org/.../sschmidt/wpan Merge branch 'bnx2x-Fix-series' Merge git://git.kernel.org/.../pablo/nf Merge branch '40GbE' of git://git.kernel.org/.../jkirsher/net-queue Merge branch 'vhost-fixes' Merge tag 'mlx5-fixes-2018-12-13' of git://git.kernel.org/.../saeed/linux Merge git://git.kernel.org/.../bpf/bpf Merge branch 'hns-fixes' Merge branch 'net-SO_TIMESTAMPING-fixes' Merge branch 'mlxsw-VXLAN-and-firmware-flashing-fixes' Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec Merge branch 'macb-DMA-race-fixes' Merge branch 'vxlan-Various-fixes' Merge git://git.kernel.org/.../bpf/bpf Merge tag 'mac80211-for-davem-2018-12-19' of git://git.kernel.org/.../jberg/mac80211 Merge tag 'wireless-drivers-for-davem-2018-12-19' of git://git.kernel.org/.../kvalo/wireless-drivers Merge branch 'rds-fixes' Merge tag 'mlx5-fixes-2018-12-19' of git://git.kernel.org/.../saeed/linux rds: Fix warning. Davide Caratti (1): net: Use __kernel_clockid_t in uapi net_stamp.h Emmanuel Grumbach (1): iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares Eric Dumazet (1): net: clear skb->tstamp in forwarding paths Florian Westphal (2): netfilter: seqadj: re-load tcp header pointer after possible head reallocation netfilter: nat: can't use dst_hold on noref dst Ganesh Goudar (1): net/tls: allocate tls context using GFP_ATOMIC Gavi Teitz (1):
[PATCH v7 1/3] x86/fpu: track AVX-512 usage of tasks
User space tools which do automated task placement need information
about AVX-512 usage of tasks, because AVX-512 usage could cause core
turbo frequency drop and impact the running task on the sibling CPU.
The XSAVE hardware structure has bits that indicate when valid state
is present in registers unique to AVX-512 use. Use these bits to
indicate when AVX-512 has been in use and add per-task AVX-512 state
timestamp tracking to context switch.
Well-written AVX-512 applications are expected to clear the AVX-512
state when not actively using AVX-512 registers, so the tracking
mechanism is imprecise and can theoretically miss AVX-512 usage during
context switch. But it has been measured to be precise enough to be
useful under real-world workloads like tensorflow and linpack.
If higher precision is required, suggest user space tools to use the
PMU-based mechanisms in combination.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index a38bf5a1e37a..e30c5b414b2c 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -411,6 +411,13 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
{
if (likely(use_xsave())) {
copy_xregs_to_kernel(>state.xsave);
+
+ /*
+* AVX512 state is tracked here because its use is
+* known to slow the max clock speed of the core.
+*/
+ if (fpu->state.xsave.header.xfeatures & XFEATURE_MASK_AVX512)
+ fpu->avx512_timestamp = jiffies;
return 1;
}
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 202c53918ecf..2e32e178e064 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -302,6 +302,13 @@ struct fpu {
*/
unsigned char initialized;
+ /*
+* @avx512_timestamp:
+*
+* Records the timestamp of AVX512 use during last context switch.
+*/
+ unsigned long avx512_timestamp;
+
/*
* @state:
*
--
2.17.1
[PATCH v7 3/3] Documentation/filesystems/proc.txt: add AVX512_elapsed_ms
Added AVX512_elapsed_ms in /proc//status. Report it in Documentation/filesystems/proc.txt Signed-off-by: Aubrey Li Cc: Peter Zijlstra Cc: Andi Kleen Cc: Tim Chen Cc: Dave Hansen Cc: Arjan van de Ven --- Documentation/filesystems/proc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 520f6a84cf50..c4be304bce69 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -197,6 +197,7 @@ read the file /proc/PID/status: Seccomp:0 voluntary_ctxt_switches:0 nonvoluntary_ctxt_switches: 1 + AVX512_elapsed_ms: 1020 This shows you nearly the same information you would get if you viewed it with the ps command. In fact, ps uses the proc file system to obtain its @@ -214,7 +215,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc//smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 4.8) +Table 1-2: Contents of the status files (as of 4.21) .. Field Content Namefilename of the executable @@ -275,6 +276,7 @@ Table 1-2: Contents of the status files (as of 4.8) Mems_allowed_list Same as previous, but in "list format" voluntary_ctxt_switches number of voluntary context switches nonvoluntary_ctxt_switches number of non voluntary context switches + AVX512_elapsed_ms time elapsed since last AVX512 use in millisecond .. Table 1-3: Contents of the statm files (as of 2.6.8-rc3) -- 2.17.1
[PATCH v7 2/3] proc: add AVX-512 usage elapsed time to /proc/pid/status
AVX-512 components use could cause core turbo frequency drop. So
it's useful to expose AVX-512 usage elapsed time as a heuristic hint
for the user space job scheduler to cluster the AVX-512 using tasks
together.
Example:
$ cat /proc/pid/status | grep AVX512_elapsed_ms
AVX512_elapsed_ms: 1020
The number '1020' denotes 1020 millisecond elapsed since last time
context switch the off-CPU task using AVX-512 components, thus the
task could cause core frequency drop.
Or:
$ cat /proc/pid/status | grep AVX512_elapsed_ms
AVX512_elapsed_ms: -1
The number '-1' indicates the task didn't use AVX-512 components
before thus unlikely has frequency drop issue.
User space tools may want to further check by:
$ perf stat --pid -e core_power.lvl2_turbo_license -- sleep 1
Performance counter stats for process id '3558':
3,251,565,961 core_power.lvl2_turbo_license
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 38
fs/proc/array.c | 5 +
2 files changed, 43 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 87a57b7642d3..c361de2bfb28 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1245,3 +1246,40 @@ int copy_user_to_xstate(struct xregs_state *xsave, const
void __user *ubuf)
return 0;
}
+
+/*
+ * Report the amount of time elapsed in millisecond since last AVX512
+ * use in the task.
+ */
+void avx512_state(struct seq_file *m, struct task_struct *task)
+{
+ unsigned long timestamp = task->thread.fpu.avx512_timestamp;
+ long delta;
+
+ if (!timestamp)
+ delta = -1;
+ else {
+ delta = (long)(jiffies - timestamp);
+ /*
+* Cap to LONG_MAX if time difference > LONG_MAX
+*/
+ if (delta < 0)
+ delta = LONG_MAX;
+ delta = jiffies_to_msecs(delta);
+ }
+
+ seq_put_decimal_ll(m, "AVX512_elapsed_ms:\t", delta);
+ seq_putc(m, '\n');
+}
+
+/*
+ * Report CPU specific thread state
+ */
+void arch_task_state(struct seq_file *m, struct task_struct *task)
+{
+ /*
+* Report AVX512 state if the processor and build option supported.
+*/
+ if (cpu_feature_enabled(X86_FEATURE_AVX512F))
+ avx512_state(m, task);
+}
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 0ceb3b6b37e7..dd88c2219f08 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -392,6 +392,10 @@ static inline void task_core_dumping(struct seq_file *m,
struct mm_struct *mm)
seq_putc(m, '\n');
}
+void __weak arch_task_state(struct seq_file *m, struct task_struct *task)
+{
+}
+
int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
@@ -414,6 +418,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
task_cpus_allowed(m, task);
cpuset_task_status_allowed(m, task);
task_context_switch_counts(m, task);
+ arch_task_state(m, task);
return 0;
}
--
2.17.1
linux-next: manual merge of the tip tree with the kbuild tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
Makefile
between commits:
65bba0423ecf ("kbuild: fix UML build error with CONFIG_GCC_PLUGINS")
059bc9fc375e ("kbuild: make 'archprepare' depend on 'scripts'")
ce2fd53a10c7 ("kbuild: descend into scripts/gcc-plugins/ via
scripts/Makefile")
from the kbuild tree and commit:
6ac389346e69 ("Revert "kbuild/Makefile: Prepare for using macros in inline
assembly code to work around asm() related GCC inlining bugs"")
from the tip 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.
--
Cheers,
Stephen Rothwell
diff --cc Makefile
index 6ae8a5382d5d,885c74b192f9..
--- a/Makefile
+++ b/Makefile
@@@ -1104,12 -1104,9 +1104,10 @@@ prepare2: prepare3 outputmakefile asm-g
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h
$(cmd_crmodverdir)
- macroprepare: prepare1 archmacros
-
- archprepare: archheaders archscripts macroprepare scripts
-archprepare: archheaders archscripts prepare1 scripts_basic
++archprepare: archheaders archscripts prepare1 scripts
-prepare0: archprepare gcc-plugins
+prepare0: archprepare
+ $(Q)$(MAKE) $(build)=scripts/mod
$(Q)$(MAKE) $(build)=.
# All the preparing..
pgpUgH0Uolzus.pgp
Description: OpenPGP digital signature
[PATCH RESEND V5 1/3] misc/pvpanic: return 0 for empty body register function
Return 0 for empty body register function normally.
Signed-off-by: Peng Hao
---
v4 --> v5 : resolve kbuild issue: handle all typo "drvier/driver"
in funtion name.
v3 --> v4 : use pcim* function instead of pci* function.
handle typo "drvier/driver" in funtion name.
v2 --> v3 : resolve kbuild issue : a uninitialized variable in some path.
v2 --> v1 : resolve kbuild issue : arch=sh don't support pci, adjust
CONFIG_PCI macro.
v1 : QEMU community requires additional PCI devices to simulate PVPANIC devices
so that some architectures can not occupy precious less than 4G of memory
space.
drivers/misc/pvpanic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 3150dc2..f84ed30 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -125,7 +125,7 @@ static void pvpanic_unregister_acpi_driver(void)
#else
static int pvpanic_register_acpi_driver(void)
{
- return -ENODEV;
+ return 0;
}
static void pvpanic_unregister_acpi_driver(void) {}
--
1.8.3.1
[PATCH RESEND V5 2/3] misc/pvpanic : add pci interface for pvpanic
Support pvpanic as a pci device in guest kernel.
Suggested-by: Andy Shevchenko
[Use pcim_* API. - Andy]
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic.c | 72 --
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index f84ed30..c30bf62 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -13,9 +13,12 @@
#include
#include
#include
+#include
#include
#include
+#define PCI_VENDOR_ID_REDHAT 0x1b36
+#define PCI_DEVICE_ID_REDHAT_PVPANIC 0x0101
static void __iomem *base;
#define PVPANIC_PANICKED(1 << 0)
@@ -172,12 +175,76 @@ static int pvpanic_mmio_remove(struct platform_device
*pdev)
.remove = pvpanic_mmio_remove,
};
+#ifdef CONFIG_PCI
+static const struct pci_device_id pvpanic_pci_id_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC),},
+ {}
+};
+
+static int pvpanic_pci_probe(struct pci_dev *pdev,
+const struct pci_device_id *ent)
+{
+ int ret;
+
+ ret = pcim_enable_device(pdev);
+ if (ret < 0)
+ return ret;
+
+ ret = pcim_iomap_regions(pdev, 1 << 0, pci_name(pdev));
+ if (ret)
+ return ret;
+
+ base = pcim_iomap_table(pdev)[0];
+
+ atomic_notifier_chain_register(_notifier_list,
+ _panic_nb);
+ return 0;
+}
+
+static void pvpanic_pci_remove(struct pci_dev *pdev)
+{
+ atomic_notifier_chain_unregister(_notifier_list,
+_panic_nb);
+}
+
+static struct pci_driver pvpanic_pci_driver = {
+ .name = "pvpanic-pci",
+ .id_table = pvpanic_pci_id_tbl,
+ .probe =pvpanic_pci_probe,
+ .remove = pvpanic_pci_remove,
+};
+
+static int pvpanic_register_pci_driver(void)
+{
+ return pci_register_driver(_pci_driver);
+}
+
+static void pvpanic_unregister_pci_driver(void)
+{
+ pci_unregister_driver(_pci_driver);
+}
+#else
+static int pvpanic_register_pci_driver(void)
+{
+ return 0;
+}
+
+static void pvpanic_unregister_pci_driver(void) {}
+#endif
+
static int __init pvpanic_mmio_init(void)
{
+ int r1, r2;
+
if (acpi_disabled)
- return platform_driver_register(_mmio_driver);
+ r1 = platform_driver_register(_mmio_driver);
+ else
+ r1 = pvpanic_register_acpi_driver();
+ r2 = pvpanic_register_pci_driver();
+ if (r1 && r2) /* all drivers register failed */
+ return 1;
else
- return pvpanic_register_acpi_driver();
+ return 0;
}
static void __exit pvpanic_mmio_exit(void)
@@ -186,6 +253,7 @@ static void __exit pvpanic_mmio_exit(void)
platform_driver_unregister(_mmio_driver);
else
pvpanic_unregister_acpi_driver();
+ pvpanic_unregister_pci_driver();
}
module_init(pvpanic_mmio_init);
--
1.8.3.1
[PATCH RESEND V5 3/3] misc/pvpanic : add pci dependency in Kconfig
Add PCI dependency for pvpanic in Kconfig. Signed-off-by: Peng Hao --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index f417b06..5ff8ca4 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -515,7 +515,7 @@ config MISC_RTSX config PVPANIC tristate "pvpanic device support" - depends on HAS_IOMEM && (ACPI || OF) + depends on HAS_IOMEM && (ACPI || OF || PCI) help This driver provides support for the pvpanic device. pvpanic is a paravirtualized device provided by QEMU; it lets a virtual machine -- 1.8.3.1
Recent VFS/LSM patches cause Kernel panic - not syncing: Can't create rootfs
Hi,
We started to see a "Can't create rootfs" panic with linux-next's
next-20181218 and next-20181219. Note: next-20181217 is good.
Our test team found the first bad commit by git-bisect:
013c7af575e5 ("vfs: Implement a filesystem superblock creation/configuration
context")
I had a look and I think another patch also helped to cause the panic:
c36d02347290 ("apparmor: Implement security hooks for the new mount API")
My kernel config for next-20181218, and my dmesg are attached.
I can always reproduce the panic every time I boot up the kernel.
My finding is: the panic happens because
start_kernel() -> vfs_caches_init() -> mnt_init() ->
sysfs_init() -> register_filesystem() -> init_mount_tree() ->
vfs_kern_mount(type, 0, "rootfs", NULL) -> vfs_get_tree() ->
security_sb_set_mnt_opts(sb, fc->security, 0, NULL) returns -EOPNOTSUPP:
int security_sb_set_mnt_opts(struct super_block *sb,
void *mnt_opts,
unsigned long kern_flags,
unsigned long *set_kern_flags)
{
return call_int_hook(sb_set_mnt_opts,
mnt_opts ? -EOPNOTSUPP : 0, sb,
mnt_opts, kern_flags, set_kern_flags);
}
This means: fc->security is not NULL in
security_sb_set_mnt_opts(sb, fc->security, 0, NULL), and the
security_hook_heads.FUNC is empty in call_int_hook().
The fc->security is assigned in this function (i.e. the line "fc->security =
afc;" ):
static int apparmor_fs_context_parse_param(struct fs_context *fc,
struct fs_parameter *param)
{
struct apparmor_fs_context *afc = fc->security;
const char *value;
size_t space = 0, k_len = strlen(param->key), len = k_len, v_len;
char *p, *q;
if (!afc) {
afc = kzalloc(sizeof(*afc), GFP_KERNEL);
fc->security = afc;
}
apparmor_fs_context_parse_param() is added recently in:
c36d02347290 ("apparmor: Implement security hooks for the new mount API")
Unluckily I know nothing about LSM, so I'm not sure if the bug is in the VFS or
LSM. Here let me Cc the related people. I suppose somebody would give a quick
fix.
Thanks!
-- Dexuan
config.txt.tar.gz
Description: config.txt.tar.gz
[0.00] Linux version 4.20.0-rc7-next-20181218+ (root@decui-1604) (gcc
version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)) #4
SMP Wed Dec
19 19:44:22 PST 2018
[0.00] Command line: BOOT_IMAGE=/boot/hv/bzImage
root=UUID=9bb51693-01d7-4323-a5e4-54b065696092 ro ignore_loglevel console=tty1
c
onsole=ttyS0
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] AMD AuthenticAMD
[0.00] Hygon HygonGenuine
[0.00] Centaur CentaurHauls
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
[0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960
bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xf7fe] usable
[0.00] BIOS-e820: [mem 0xf7ff-0xf7ffefff] ACPI data
[0.00] BIOS-e820: [mem 0xf7fff000-0xf7ff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0001-0x000287ff] usable
[0.00] printk: debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.3 present.
[0.00] DMI: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS
090007 05/18/2018
[0.00] Hypervisor detected: Microsoft Hyper-V
[0.00] Hyper-V: features 0x2e7f, hints 0x20c2c
[0.00] Hyper-V Host Build:17713-10.0-1-0.1044
[0.00] Hyper-V: LAPIC Timer Frequency: 0xc3500
[0.00] tsc: Marking TSC unstable due to running on Hyper-V
[0.00] Hyper-V: Using hypercall for remote TLB flush
[0
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 19/12/2018 14:40, Aneesh Kumar K.V wrote: > This helper does a get_user_pages_fast and if it find pages in the CMA area > it will try to migrate them before taking page reference. This makes sure that > we don't keep non-movable pages (due to page reference count) in the CMA area. > Not able to move pages out of CMA area result in CMA allocation failures. > > Signed-off-by: Aneesh Kumar K.V > --- > include/linux/hugetlb.h | 2 + > include/linux/migrate.h | 3 + > mm/hugetlb.c| 4 +- > mm/migrate.c| 139 > 4 files changed, 146 insertions(+), 2 deletions(-) > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 087fd5f48c91..1eed0cdaec0e 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h > @@ -371,6 +371,8 @@ struct page *alloc_huge_page_nodemask(struct hstate *h, > int preferred_nid, > nodemask_t *nmask); > struct page *alloc_huge_page_vma(struct hstate *h, struct vm_area_struct > *vma, > unsigned long address); > +struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask, > + int nid, nodemask_t *nmask); > int huge_add_to_page_cache(struct page *page, struct address_space *mapping, > pgoff_t idx); > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > index f2b4abbca55e..d82b35afd2eb 100644 > --- a/include/linux/migrate.h > +++ b/include/linux/migrate.h > @@ -286,6 +286,9 @@ static inline int migrate_vma(const struct > migrate_vma_ops *ops, > } > #endif /* IS_ENABLED(CONFIG_MIGRATE_VMA_HELPER) */ > > +extern int get_user_pages_cma_migrate(unsigned long start, int nr_pages, int > write, > + struct page **pages); ah, sorry for commenting the same patch again but ./scripts/checkpatch.pl complains a log on this patch. -- Alexey
Re: [PATCH V5 1/3] mm: Add get_user_pages_cma_migrate
On 19/12/2018 14:40, Aneesh Kumar K.V wrote:
> This helper does a get_user_pages_fast and if it find pages in the CMA area
> it will try to migrate them before taking page reference. This makes sure that
> we don't keep non-movable pages (due to page reference count) in the CMA area.
> Not able to move pages out of CMA area result in CMA allocation failures.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> include/linux/hugetlb.h | 2 +
> include/linux/migrate.h | 3 +
> mm/hugetlb.c| 4 +-
> mm/migrate.c| 139
> 4 files changed, 146 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 087fd5f48c91..1eed0cdaec0e 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -371,6 +371,8 @@ struct page *alloc_huge_page_nodemask(struct hstate *h,
> int preferred_nid,
> nodemask_t *nmask);
> struct page *alloc_huge_page_vma(struct hstate *h, struct vm_area_struct
> *vma,
> unsigned long address);
> +struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
> + int nid, nodemask_t *nmask);
> int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
> pgoff_t idx);
>
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index f2b4abbca55e..d82b35afd2eb 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -286,6 +286,9 @@ static inline int migrate_vma(const struct
> migrate_vma_ops *ops,
> }
> #endif /* IS_ENABLED(CONFIG_MIGRATE_VMA_HELPER) */
>
> +extern int get_user_pages_cma_migrate(unsigned long start, int nr_pages, int
> write,
> + struct page **pages);
> +
> #endif /* CONFIG_MIGRATION */
>
> #endif /* _LINUX_MIGRATE_H */
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 7f2a28ab46d5..faf3102ae45e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1585,8 +1585,8 @@ static struct page *alloc_surplus_huge_page(struct
> hstate *h, gfp_t gfp_mask,
> return page;
> }
>
> -static struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
> - int nid, nodemask_t *nmask)
> +struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
> + int nid, nodemask_t *nmask)
> {
> struct page *page;
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f7e4bfdc13b7..d564558fba03 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2946,3 +2946,142 @@ int migrate_vma(const struct migrate_vma_ops *ops,
> }
> EXPORT_SYMBOL(migrate_vma);
> #endif /* defined(MIGRATE_VMA_HELPER) */
> +
> +static struct page *new_non_cma_page(struct page *page, unsigned long
> private)
> +{
> + /*
> + * We want to make sure we allocate the new page from the same node
> + * as the source page.
> + */
> + int nid = page_to_nid(page);
> + /*
> + * Trying to allocate a page for migration. Ignore allocation
> + * failure warnings
> + */
> + gfp_t gfp_mask = GFP_USER | __GFP_THISNODE | __GFP_NOWARN;
> +
> + if (PageHighMem(page))
> + gfp_mask |= __GFP_HIGHMEM;
> +
> +#ifdef CONFIG_HUGETLB_PAGE
> + if (PageHuge(page)) {
> + struct hstate *h = page_hstate(page);
> + /*
> + * We don't want to dequeue from the pool because pool pages
> will
> + * mostly be from the CMA region.
> + */
> + return alloc_migrate_huge_page(h, gfp_mask, nid, NULL);
> + }
> +#endif
> + if (PageTransHuge(page)) {
> + struct page *thp;
> + /*
> + * ignore allocation failure warnings
> + */
> + gfp_t thp_gfpmask = GFP_TRANSHUGE | __GFP_THISNODE |
> __GFP_NOWARN;
> +
> + /*
> + * Remove the movable mask so that we don't allocate from
> + * CMA area again.
> + */
> + thp_gfpmask &= ~__GFP_MOVABLE;
> + thp = __alloc_pages_node(nid, thp_gfpmask, HPAGE_PMD_ORDER);
> + if (!thp)
> + return NULL;
> + prep_transhuge_page(thp);
> + return thp;
> + }
> +
> + return __alloc_pages_node(nid, gfp_mask, 0);
> +}
> +
> +/**
> + * get_user_pages_cma_migrate() - pin user pages in memory by migrating
> pages in CMA region
> + * @start: starting user address
> + * @nr_pages:number of pages from start to pin
> + * @write: whether pages will be written to
> + * @pages: array that receives pointers to the pages pinned.
> + * Should be at least nr_pages long.
> + *
> + * Attempt to pin user pages in memory without taking mm->mmap_sem.
> + * If not successful, it will fall back to taking the lock and
> + * calling get_user_pages().
> + *
> + * If the pinned pages are backed by
Re: [PATCH 31/41] scsi: mpt3sas: mpt3sas_scsih: Mark expected switch fall-through
Hi Gustavo,
This patch may not apply smoothly over 4.21/scsi-queue.
Our previous patch for Aero had some changes in this switch case.
Can you resend this patch with latest code base ?
Thanks,
Suganath prabu
On Thu, Dec 20, 2018 at 5:37 AM Gustavo A. R. Silva
wrote:
>
> Hi,
>
> Friendly ping:
>
> Who can ack or review this patch, please?
>
> Thanks
> --
> Gustavo
>
> On 11/27/18 10:32 PM, Gustavo A. R. Silva wrote:
> > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > where we are expecting to fall through.
> >
> > Addresses-Coverity-ID: 1475400 ("Missing break in switch")
> > Signed-off-by: Gustavo A. R. Silva
> > ---
> > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > index 5b9806d0719e..920b80ce4748 100644
> > --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > @@ -10370,6 +10370,7 @@ _scsih_probe(struct pci_dev *pdev, const struct
> > pci_device_id *id)
> > case MPI26_MFGPAGE_DEVID_CFG_SEC_3916:
> > dev_info(>dev,
> > "HBA is in Configurable Secure mode\n");
> > + /* fall through */
> > case MPI26_MFGPAGE_DEVID_SAS3508:
> > case MPI26_MFGPAGE_DEVID_SAS3508_1:
> > case MPI26_MFGPAGE_DEVID_SAS3408:
> >
Re: [PATCH v6 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver
Hi Shawn,
On 2018-12-20 06:31, Shawn Guo wrote:
It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
Signed-off-by: Shawn Guo
---
+
+/* PHY register and bit definitions */
+#define PHY_CTRL_COMMON0 0x078
+#define SIDDQ BIT(2)
+#define PHY_IRQ_CMD0x0d0
+#define PHY_INTR_MASK0 0x0d4
+#define PHY_INTR_CLEAR00x0dc
+#define DPDM_MASK 0x1e
+#define DP_1_0 BIT(4)
+#define DP_0_1 BIT(3)
+#define DM_1_0 BIT(2)
+#define DM_0_1 BIT(1)
Can we rename these to something more readable? e.g.:
#define DP_FALL_INT_ENBIT(4)
#define DP_RISE_INT_ENBIT(3)
...
+
+enum hsphy_voltage {
+ VOL_NONE,
+ VOL_MIN,
+ VOL_MAX,
+ VOL_NUM,
+};
+
+enum hsphy_vreg {
+ VDD,
+ VDDA_1P8,
+ VDDA_3P3,
+ VREG_NUM,
+};
+
+struct hsphy_init_seq {
+ int offset;
+ int val;
+ int delay;
+};
+
+struct hsphy_data {
+ const struct hsphy_init_seq *init_seq;
+ unsigned int init_seq_num;
+};
+
+struct hsphy_priv {
nit-pick - indentation for following structure members?
+ void __iomem *base;
+ struct clk_bulk_data *clks;
+ int num_clks;
+ struct reset_control *phy_reset;
+ struct reset_control *por_reset;
+ struct regulator_bulk_data vregs[VREG_NUM];
+ unsigned int voltages[VREG_NUM][VOL_NUM];
+ const struct hsphy_data *data;
+ bool cable_connected;
You can get cable-connected state from "enum phy_mode mode" which
is present in this driver.
E.g. cable_connected is false if mode is neither HOST nor DEVICE.
+ struct extcon_dev *vbus_edev;
+ struct notifier_block vbus_notify;
extcons not needed if you use "mode" for the same purpose.
+ enum phy_mode mode;
+};
+
+
+static int qcom_snps_hsphy_vbus_notifier(struct notifier_block *nb,
+unsigned long event, void *ptr)
+{
+ struct hsphy_priv *priv = container_of(nb, struct hsphy_priv,
+ vbus_notify);
+ priv->cable_connected = !!event;
+ return 0;
+}
+
+static int qcom_snps_hsphy_power_on(struct phy *phy)
Can you instead merge this power_on function with phy_init?
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+ int ret;
+
+ if (priv->cable_connected) {
Why distinguish between cable connected vs not-connected?
+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+ if (ret)
+ return ret;
+ qcom_snps_hsphy_disable_hv_interrupts(priv);
+ } else {
+ ret = qcom_snps_hsphy_enable_regulators(priv);
+ if (ret)
+ return ret;
+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+ if (ret)
+ return ret;
+ qcom_snps_hsphy_exit_retention(priv);
+ }
+
+ return 0;
+}
+
+static int qcom_snps_hsphy_power_off(struct phy *phy)
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+
+ if (priv->cable_connected) {
+ qcom_snps_hsphy_enable_hv_interrupts(priv);
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+ } else {
+ qcom_snps_hsphy_enter_retention(priv);
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+ qcom_snps_hsphy_disable_regulators(priv);
+ }
+
+ return 0;
+}
+
..
+static const struct phy_ops qcom_snps_hsphy_ops = {
+ .init = qcom_snps_hsphy_init,
+ .power_on = qcom_snps_hsphy_power_on,
+ .power_off = qcom_snps_hsphy_power_off,
+ .set_mode = qcom_snps_hsphy_set_mode,
.phy_exit()?
I believe that is needed as dwc3 core driver performs
phy_exit/phy_init across pm_suspend/resume.
+ .owner = THIS_MODULE,
+};
+
Re: [PATCH] ARC: adjust memblock_reserve of kernel memory
On 12/19/18 8:16 AM, Eugeniy Paltsev wrote: > In setup_arch_memory we reserve the memory area wherein the kernel > is located. Current implementation may reserve more memory than > it actually required in case of CONFIG_LINUX_LINK_BASE is not > equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate > start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE > and end of the region relatively to the CONFIG_LINUX_RAM_BASE. > > For example in case of HSDK board we wasted 256MiB of physical memory: > --->8-- > Memory: 770416K/1048576K available (5496K kernel code, > 240K rwdata, 1064K rodata, 2200K init, 275K bss, > 278160K reserved, 0K cma-reserved) > --->8-- > > Fix that. > > Cc: sta...@vger.kernel.org For backports, please also check how far back this needs to be applied (else we get bot emails specifying they don't apply to ver x, y z) > Signed-off-by: Eugeniy Paltsev > --- > arch/arc/mm/init.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c > index f8fe5668b30f..a56e6a8ed259 100644 > --- a/arch/arc/mm/init.c > +++ b/arch/arc/mm/init.c > @@ -137,7 +137,8 @@ void __init setup_arch_memory(void) >*/ > > memblock_add_node(low_mem_start, low_mem_sz, 0); > - memblock_reserve(low_mem_start, __pa(_end) - low_mem_start); > + memblock_reserve(CONFIG_LINUX_LINK_BASE, > + __pa(_end) - CONFIG_LINUX_LINK_BASE); > > #ifdef CONFIG_BLK_DEV_INITRD > if (initrd_start) So I looked into the history for restricting stable, and it seems this was introduced with our earlier work for HSDK. Before commit 9ed68785f7f this code was ok, since low_mem_start = CONFIG_LINUX_LINK_BASE. With the patch we changed low_mem_start to CONFIG_LINUX_RAM_BASE and missed this. -Vineet
[PATCH] brcm80211: remove set but not used variables 'phybw40, maxtargetpwr'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:1202:5: warning:
variable 'phybw40' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4625:5: warning:
variable 'phybw40' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4834:5: warning:
variable 'phybw40' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:3085:17:
warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4215:17:
warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
.../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
index e78a93a..c6e107f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -1199,8 +1199,6 @@ wlc_lcnphy_rx_iq_est(struct brcms_phy *pi,
{
int wait_count = 0;
bool result = true;
- u8 phybw40;
- phybw40 = CHSPEC_IS40(pi->radio_chanspec);
mod_phy_reg(pi, 0x6da, (0x1 << 5), (1) << 5);
@@ -3082,7 +3080,7 @@ static void wlc_lcnphy_tx_pwr_ctrl_init(struct
brcms_phy_pub *ppi)
u8 bbmult;
struct phytbl_info tab;
s32 a1, b0, b1;
- s32 tssi, pwr, maxtargetpwr, mintargetpwr;
+ s32 tssi, pwr, mintargetpwr;
bool suspend;
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -3119,7 +3117,6 @@ static void wlc_lcnphy_tx_pwr_ctrl_init(struct
brcms_phy_pub *ppi)
b0 = pi->txpa_2g[0];
b1 = pi->txpa_2g[1];
a1 = pi->txpa_2g[2];
- maxtargetpwr = wlc_lcnphy_tssi2dbm(10, a1, b0, b1);
mintargetpwr = wlc_lcnphy_tssi2dbm(125, a1, b0, b1);
tab.tbl_id = LCNPHY_TBL_ID_TXPWRCTL;
@@ -4212,7 +4209,7 @@ static void wlc_lcnphy_periodic_cal(struct brcms_phy *pi)
s8 index;
struct phytbl_info tab;
s32 a1, b0, b1;
- s32 tssi, pwr, maxtargetpwr, mintargetpwr;
+ s32 tssi, pwr, mintargetpwr;
struct brcms_phy_lcnphy *pi_lcn = pi->u.pi_lcnphy;
pi->phy_lastcal = pi->sh->now;
@@ -4249,7 +4246,6 @@ static void wlc_lcnphy_periodic_cal(struct brcms_phy *pi)
b0 = pi->txpa_2g[0];
b1 = pi->txpa_2g[1];
a1 = pi->txpa_2g[2];
- maxtargetpwr = wlc_lcnphy_tssi2dbm(10, a1, b0, b1);
mintargetpwr = wlc_lcnphy_tssi2dbm(125, a1, b0, b1);
tab.tbl_id = LCNPHY_TBL_ID_TXPWRCTL;
@@ -4622,13 +4618,10 @@ static void wlc_lcnphy_radio_init(struct brcms_phy *pi)
static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
{
uint idx;
- u8 phybw40;
struct phytbl_info tab;
const struct phytbl_info *tb;
u32 val;
- phybw40 = CHSPEC_IS40(pi->radio_chanspec);
-
for (idx = 0; idx < dot11lcnphytbl_info_sz_rev0; idx++)
wlc_lcnphy_write_table(pi, _info_rev0[idx]);
@@ -4831,9 +4824,7 @@ static void wlc_lcnphy_baseband_init(struct brcms_phy *pi)
void wlc_phy_init_lcnphy(struct brcms_phy *pi)
{
- u8 phybw40;
struct brcms_phy_lcnphy *pi_lcn = pi->u.pi_lcnphy;
- phybw40 = CHSPEC_IS40(pi->radio_chanspec);
pi_lcn->lcnphy_cal_counter = 0;
pi_lcn->lcnphy_cal_temper = pi_lcn->lcnphy_rawtempsense;
--
2.7.0
Re: [PATCH] ARC: adjust memblock_reserve of kernel memory
On 12/19/18 8:16 AM, Eugeniy Paltsev wrote: > In setup_arch_memory we reserve the memory area wherein the kernel > is located. Current implementation may reserve more memory than > it actually required in case of CONFIG_LINUX_LINK_BASE is not > equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate > start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE > and end of the region relatively to the CONFIG_LINUX_RAM_BASE. > > For example in case of HSDK board we wasted 256MiB of physical memory: > --->8-- > Memory: 770416K/1048576K available (5496K kernel code, > 240K rwdata, 1064K rodata, 2200K init, 275K bss, > 278160K reserved, 0K cma-reserved) > --->8-- > > Fix that. > > Cc: sta...@vger.kernel.org > Signed-off-by: Eugeniy Paltsev LGTM. I presume you have booted HSDK with it and done some smoke testing. -Vineet
Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
On Wed, Dec 19, 2018 at 11:51 PM Christoph Hellwig wrote: > > On Wed, Dec 19, 2018 at 05:18:35PM +0900, Tomasz Figa wrote: > > The existing code that deals with dma_alloc_attrs() without > > DMA_ATTR_NON_CONSISTENT would just call dma_get_sgtable_attrs() like > > here: > > I know. And dma_get_sgtable_attrs is fundamentally flawed and we > need to kill this interface as it just can't worked with virtually > tagged cases. It is a prime example for an interface that looks > nice and simple but is plain wrong. Got it, thanks. I haven't been following the problems with virtually tagged cases, would you mind sharing some background, so that we can consider it when adding non-consistent allocations to VB2? Best regards, Tomasz
[PATCH net-next 1/9] net: hns3: refine the handle for hns3_nic_net_open/stop()
From: Jian Shen
When triggering nic down, there is a time window between bringing down
the protocol stack and stopping the work task. If the net is up in the
time window, it may bring up the protocol stack again.
This patch fixes it by stop the work task at the beginning of
hns3_nic_net_stop(). To keep symmetrical, start the work task at the
end of hns3_nic_net_open().
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 8
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 22 +++---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 18 ++
4 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 845d43d..36eab37 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -461,6 +461,7 @@ struct hnae3_ae_ops {
unsigned long (*ae_dev_reset_cnt)(struct hnae3_handle *handle);
int (*set_gro_en)(struct hnae3_handle *handle, int enable);
u16 (*get_global_queue_id)(struct hnae3_handle *handle, u16 queue_id);
+ void (*set_timer_task)(struct hnae3_handle *handle, bool enable);
};
struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index d060029..becbf86 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -379,6 +379,7 @@ static int hns3_nic_net_up(struct net_device *netdev)
static int hns3_nic_net_open(struct net_device *netdev)
{
+ struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = hns3_get_handle(netdev);
struct hnae3_knic_private_info *kinfo;
int i, ret;
@@ -405,6 +406,9 @@ static int hns3_nic_net_open(struct net_device *netdev)
kinfo->prio_tc[i]);
}
+ if (h->ae_algo->ops->set_timer_task)
+ h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
+
return 0;
}
@@ -437,10 +441,14 @@ static void hns3_nic_net_down(struct net_device *netdev)
static int hns3_nic_net_stop(struct net_device *netdev)
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
+ struct hnae3_handle *h = hns3_get_handle(netdev);
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, >state))
return 0;
+ if (h->ae_algo->ops->set_timer_task)
+ h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
+
netif_tx_stop_all_queues(netdev);
netif_carrier_off(netdev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index d0e84de..a12cb14 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5295,6 +5295,20 @@ static void hclge_reset_tqp_stats(struct hnae3_handle
*handle)
}
}
+static void hclge_set_timer_task(struct hnae3_handle *handle, bool enable)
+{
+ struct hclge_vport *vport = hclge_get_vport(handle);
+ struct hclge_dev *hdev = vport->back;
+
+ if (enable) {
+ mod_timer(>service_timer, jiffies + HZ);
+ } else {
+ del_timer_sync(>service_timer);
+ cancel_work_sync(>service_task);
+ clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
+ }
+}
+
static int hclge_ae_start(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
@@ -5303,7 +5317,6 @@ static int hclge_ae_start(struct hnae3_handle *handle)
/* mac enable */
hclge_cfg_mac_mode(hdev, true);
clear_bit(HCLGE_STATE_DOWN, >state);
- mod_timer(>service_timer, jiffies + HZ);
hdev->hw.mac.link = 0;
/* reset tqp stats */
@@ -5321,10 +5334,6 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
set_bit(HCLGE_STATE_DOWN, >state);
- del_timer_sync(>service_timer);
- cancel_work_sync(>service_task);
- clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
-
/* If it is not PF reset, the firmware will disable the MAC,
* so it only need to stop phy here.
*/
@@ -5341,8 +5350,6 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
/* reset tqp stats */
hclge_reset_tqp_stats(handle);
- del_timer_sync(>service_timer);
- cancel_work_sync(>service_task);
hclge_update_link_status(hdev);
}
@@ -7996,6 +8003,7 @@ static int hclge_gro_en(struct hnae3_handle *handle, int
enable)
.ae_dev_reset_cnt = hclge_ae_dev_reset_cnt,
.set_gro_en = hclge_gro_en,
.get_global_queue_id = hclge_covert_handle_qid_global,
+ .set_timer_task = hclge_set_timer_task,
};
static struct
[PATCH net-next 5/9] net: hns3: reset tqp while doing DOWN operation
From: Huazhong Tan
While doing DOWN operation, the driver will reclaim the memory which has
already used for TX. If the hardware is processing this memory, it will
cause a RCB error to the hardware. According the hardware's description,
the driver should reset the tqp before reclaim the memory during DOWN.
Signed-off-by: Huazhong Tan
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 0b04d04..98ae282 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5331,6 +5331,7 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_dev *hdev = vport->back;
+ int i;
set_bit(HCLGE_STATE_DOWN, >state);
@@ -5343,6 +5344,9 @@ static void hclge_ae_stop(struct hnae3_handle *handle)
return;
}
+ for (i = 0; i < handle->kinfo.num_tqps; i++)
+ hclge_reset_tqp(handle, i);
+
/* Mac disable */
hclge_cfg_mac_mode(hdev, false);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 919c3aa..156242f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1870,9 +1870,13 @@ static int hclgevf_ae_start(struct hnae3_handle *handle)
static void hclgevf_ae_stop(struct hnae3_handle *handle)
{
struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ int i;
set_bit(HCLGEVF_STATE_DOWN, >state);
+ for (i = 0; i < handle->kinfo.num_tqps; i++)
+ hclgevf_reset_tqp(handle, i);
+
/* reset tqp stats */
hclgevf_reset_tqp_stats(handle);
hclgevf_update_link_status(hdev, 0);
--
1.9.1
[PATCH net-next 3/9] net: hns3: fix a bug caused by udelay
udelay() in driver may always occupancy processor. If there is only
one cpu in system, the VF driver may initialize fail when insmod
PF and VF driver in the same system. This patch use msleep() to free
cpu when VF wait PF message.
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
index ef9c8e6..84653f5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
@@ -26,7 +26,7 @@ static int hclgevf_get_mbx_resp(struct hclgevf_dev *hdev, u16
code0, u16 code1,
u8 *resp_data, u16 resp_len)
{
#define HCLGEVF_MAX_TRY_TIMES 500
-#define HCLGEVF_SLEEP_USCOEND 1000
+#define HCLGEVF_SLEEP_USECOND 1000
struct hclgevf_mbx_resp_status *mbx_resp;
u16 r_code0, r_code1;
int i = 0;
@@ -43,7 +43,7 @@ static int hclgevf_get_mbx_resp(struct hclgevf_dev *hdev, u16
code0, u16 code1,
if (test_bit(HCLGEVF_STATE_CMD_DISABLE, >state))
return -EIO;
- udelay(HCLGEVF_SLEEP_USCOEND);
+ usleep_range(HCLGEVF_SLEEP_USECOND, HCLGEVF_SLEEP_USECOND * 2);
i++;
}
--
1.9.1
[PATCH net-next 6/9] net: hns3: fix vf id check issue when add flow director rule
From: Jian Shen
When add flow director fule for vf, the vf id is used as array
subscript before valid checking, which may cause memory overflow.
Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow
director")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 98ae282..9f89858 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -4677,6 +4677,13 @@ static int hclge_add_fd_entry(struct hnae3_handle
*handle,
u8 vf = ethtool_get_flow_spec_ring_vf(fs->ring_cookie);
u16 tqps;
+ if (vf > hdev->num_req_vfs) {
+ dev_err(>pdev->dev,
+ "Error: vf id (%d) > max vf num (%d)\n",
+ vf, hdev->num_req_vfs);
+ return -EINVAL;
+ }
+
dst_vport_id = vf ? hdev->vport[vf].vport_id : vport->vport_id;
tqps = vf ? hdev->vport[vf].alloc_tqps : vport->alloc_tqps;
@@ -4687,13 +4694,6 @@ static int hclge_add_fd_entry(struct hnae3_handle
*handle,
return -EINVAL;
}
- if (vf > hdev->num_req_vfs) {
- dev_err(>pdev->dev,
- "Error: vf id (%d) > max vf num (%d)\n",
- vf, hdev->num_req_vfs);
- return -EINVAL;
- }
-
action = HCLGE_FD_ACTION_ACCEPT_PACKET;
q_index = ring;
}
--
1.9.1
[PATCH net-next 4/9] net: hns3: add max vector number check for pf
From: Jian Shen
Each pf supports max 64 vectors and 128 tqps. For 2p/4p core scenario,
there may be more than 64 cpus online. So the result of min_t(u16,
num_Online_cpus(), tqp_num) may be more than 64. This patch adds check
for the vector number.
Fixes: dd38c72604dc ("net: hns3: fix for coalesce configuration lost during
reset")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index becbf86..624b8a7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3118,6 +3118,8 @@ static int hns3_nic_init_vector_data(struct hns3_nic_priv
*priv)
static int hns3_nic_alloc_vector_data(struct hns3_nic_priv *priv)
{
+#define HNS3_VECTOR_PF_MAX_NUM 64
+
struct hnae3_handle *h = priv->ae_handle;
struct hns3_enet_tqp_vector *tqp_vector;
struct hnae3_vector_info *vector;
@@ -3130,6 +3132,8 @@ static int hns3_nic_alloc_vector_data(struct
hns3_nic_priv *priv)
/* RSS size, cpu online and vector_num should be the same */
/* Should consider 2p/4p later */
vector_num = min_t(u16, num_online_cpus(), tqp_num);
+ vector_num = min_t(u16, vector_num, HNS3_VECTOR_PF_MAX_NUM);
+
vector = devm_kcalloc(>dev, vector_num, sizeof(*vector),
GFP_KERNEL);
if (!vector)
--
1.9.1
[PATCH net-next 9/9] net: hns3: remove redundant variable initialization
This patch removes the redundant variable initialization,
as driver will devm_kzalloc to set value to hdev soon.
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 156242f..82103d5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1721,7 +1721,7 @@ static int hclgevf_configure(struct hclgevf_dev *hdev)
static int hclgevf_alloc_hdev(struct hnae3_ae_dev *ae_dev)
{
struct pci_dev *pdev = ae_dev->pdev;
- struct hclgevf_dev *hdev = ae_dev->priv;
+ struct hclgevf_dev *hdev;
hdev = devm_kzalloc(>dev, sizeof(*hdev), GFP_KERNEL);
if (!hdev)
--
1.9.1
[PATCH -next] scsi: qla4xxx: check return code of qla4xxx_copy_from_fwddb_param
The return code should be check while qla4xxx_copy_from_fwddb_param fails. Signed-off-by: YueHaibing --- drivers/scsi/qla4xxx/ql4_os.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index 949e186..1bc4db6 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -7232,6 +7232,8 @@ static int qla4xxx_sysfs_ddb_tgt_create(struct scsi_qla_host *ha, rc = qla4xxx_copy_from_fwddb_param(fnode_sess, fnode_conn, fw_ddb_entry); + if (rc) + goto free_sess; ql4_printk(KERN_INFO, ha, "%s: sysfs entry %s created\n", __func__, fnode_sess->dev.kobj.name); -- 2.7.0
[PATCH net-next 0/9] net: hns3: code optimizations & bugfixes for HNS3 driver
This patchset includes bugfixes and code optimizations for the HNS3 ethernet controller driver Huazhong Tan (1): net: hns3: reset tqp while doing DOWN operation Jian Shen (5): net: hns3: refine the handle for hns3_nic_net_open/stop() net: hns3: change default tc state to close net: hns3: add max vector number check for pf net: hns3: fix vf id check issue when add flow director rule net: hns3: don't restore rules when flow director is disabled Peng Li (3): net: hns3: fix a bug caused by udelay net: hns3: fix the descriptor index when get rss type net: hns3: remove redundant variable initialization drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 21 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 46 +++--- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 24 --- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 4 +- 5 files changed, 73 insertions(+), 23 deletions(-) -- 1.9.1
[PATCH net-next 2/9] net: hns3: change default tc state to close
From: Jian Shen In original codes, default tc value is set to the max tc. It's more reasonable to close tc by changing default tc value to 1. Users can enable it with lldp tool when they want to use tc. Signed-off-by: Jian Shen Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index a12cb14..0b04d04 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -960,7 +960,7 @@ static int hclge_configure(struct hclge_dev *hdev) hdev->pfc_max = hdev->tc_max; } - hdev->tm_info.num_tc = hdev->tc_max; + hdev->tm_info.num_tc = 1; /* Currently not support uncontiuous tc */ for (i = 0; i < hdev->tm_info.num_tc; i++) -- 1.9.1
[PATCH net-next 8/9] net: hns3: fix the descriptor index when get rss type
Driver gets rss information from the last descriptor of the packet.
When driver handle the rss type, ring->next_to_clean indicates the
first descriptor of next packet.
This patch fix the descriptor index with "ring->next_to_clean - 1".
Fixes: 232fc64b6e62 ("net: hns3: Add HW RSS hash information to RX skb")
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 624b8a7..d3b9aaf 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2550,9 +2550,16 @@ static void hns3_set_gro_param(struct sk_buff *skb, u32
l234info,
static void hns3_set_rx_skb_rss_type(struct hns3_enet_ring *ring,
struct sk_buff *skb)
{
- struct hns3_desc *desc = >desc[ring->next_to_clean];
struct hnae3_handle *handle = ring->tqp->handle;
enum pkt_hash_types rss_type;
+ struct hns3_desc *desc;
+ int last_bd;
+
+ /* When driver handle the rss type, ring->next_to_clean indicates the
+* first descriptor of next packet, need -1 here.
+*/
+ last_bd = (ring->next_to_clean - 1 + ring->desc_num) % ring->desc_num;
+ desc = >desc[last_bd];
if (le32_to_cpu(desc->rx.rss_hash))
rss_type = handle->kinfo.rss_type;
--
1.9.1
[PATCH net-next 7/9] net: hns3: don't restore rules when flow director is disabled
From: Jian Shen
When user disables flow director, all the rules will be disabled. But
when reset happens, it will restore all the rules again. It's not
reasonable. This patch fixes it by add flow director status check before
restore fules.
Fixes: 6871af29b3ab ("net: hns3: Add reset handle for flow director")
Fixes: c17852a8932f ("net: hns3: Add support for enable/disable flow director")
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 9f89858..f7637c0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -4808,6 +4808,10 @@ static int hclge_restore_fd_entries(struct hnae3_handle
*handle)
if (!hnae3_dev_fd_supported(hdev))
return 0;
+ /* if fd is disabled, should not restore it when reset */
+ if (!hdev->fd_cfg.fd_en)
+ return 0;
+
hlist_for_each_entry_safe(rule, node, >fd_rule_list, rule_node) {
ret = hclge_config_action(hdev, HCLGE_FD_STAGE_1, rule);
if (!ret)
--
1.9.1
RE: [PATCH] arm64: dts: nxp: ls208xa: add more thermal zone support
> -Original Message- > From: Shawn Guo > Sent: 2018年12月19日 12:08 > To: Andy Tang > Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; > daniel.lezc...@linaro.org; linux-kernel@vger.kernel.org; Leo Li > ; robh...@kernel.org; rui.zh...@intel.com; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH] arm64: dts: nxp: ls208xa: add more thermal zone support > > On Tue, Dec 18, 2018 at 07:01:32AM +, Andy Tang wrote: > > Hi, > > > > PING. > > > > BR, > > Andy > > > > > -Original Message- > > > From: Yuantian Tang > > > Sent: 2018年10月31日 12:48 > > > To: shawn...@kernel.org > > > Cc: Leo Li ; robh...@kernel.org; > > > mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > rui.zh...@intel.com; daniel.lezc...@linaro.org; Andy Tang > > > > > > Subject: [PATCH] arm64: dts: nxp: ls208xa: add more thermal zone > > > support > > > > > > Ls208xa has several thermal sensors. Add all the sensor id to dts to > > > enable them. > > > > > > To make the dts cleaner, re-organize the nodes to split out the > > > common part so that it can be shared with other SoCs. > > > > > > Signed-off-by: Yuantian Tang > > Please take a look at patch below. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.kernel.org%2Fpatch%2F10685815%2Fdata=02%7C01%7Candy.tang > %40nxp.com%7C440d607feede45068dc608d66567c978%7C686ea1d3bc2b4c6fa > 92cd99c5c301635%7C0%7C0%7C636807893765936983sdata=QC%2By9f > mvI42t9eS3LS4YGD23Kqq6EUD0EpIGnDEDhrA%3Dreserved=0 > Thanks, will rebase my patch. BR, Andy > Shawn
[RFC][PATCH v2][RESEND] string.h: Add strncmp_prefix() helper macro
[ Resending because I missed adding Joe to the Cc list ]
A discussion came up in the trace triggers thread about converting a
bunch of:
strncmp(str, "const", sizeof("const") - 1)
use cases into a helper macro. It started with:
#define strncmp_const(str, const) \
strncmp(str, const, sizeof(const) - 1)
But then Joe Perches mentioned that if a const is not used, the
sizeof() will be the size of a pointer, which can be bad. And that
gcc will optimize strlen("const") into "sizeof("const") - 1".
Thinking about this more, a quick grep in the kernel tree found several
(thousands!) of cases that use this construct. A quick grep also
revealed that there's probably several bugs in that use case. Some are
that people forgot the "- 1" (which I found) and others could be that
the constant for the sizeof is different than the constant (although, I
haven't found any of those, but I also didn't look hard).
I figured the best thing to do is to create a helper macro and place it
into include/linux/string.h. And go around and fix all the open coded
versions of it later.
I plan on only applying this patch and updating the tracing hooks for
this merge window. And perhaps use it to fix some of the bugs that were
found.
I was going to just use:
#define strncmp_prefix(str, prefix) \
strncmp(str, prefix, strlen(prefix))
but then realized that "prefix" is used twice, and will break if
someone does something like:
strncmp_prefix(str, ptr++);
So instead I check with __builtin_constant_p() to see if the second
parameter is truly a constant, which I use sizeof() anyway (why bother
gcc to optimize it, if we already know it's a constant), and copy the
parameter into a local variable and use that local variable for the non
constant part (with strlen).
Link:
http://lkml.kernel.org/r/e3e754f2bd18e56eaa8baf79bee619316ebf4cfc.1545161087.git.tom.zanu...@linux.intel.com
Signed-off-by: Steven Rostedt (VMware)
---
Changes since v1:
- Sending this time as Bryana's dad
- Moved the assignment of the non constant into the non constant block
(Pointed out by Joe Perches)
- Added "typeof(prefix)" to define the non constant variable
(Suggested by Joe Perches)
diff --git a/include/linux/string.h b/include/linux/string.h
index 27d0482e5e05..a998a5ef 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -14,6 +14,28 @@ extern void *memdup_user(const void __user *,
size_t); extern void *vmemdup_user(const void __user *, size_t);
extern void *memdup_user_nul(const void __user *, size_t);
+/*
+ * A common way to test a prefix of a string is to do:
+ * strncmp(str, prefix, sizeof(prefix) - 1)
+ *
+ * But this can lead to bugs due to typos, or if prefix is a pointer
+ * and not a constant. Instead use strncmp_prefix().
+ */
+#define strncmp_prefix(str,
prefix) \
+
({ \
+ int
strcmp_prefix_ret; \
+ if (__builtin_constant_p())
{ \
+ strcmp_prefix_ret
= \
+ strncmp(str, prefix, sizeof(prefix) -
1); \
+ } else
{ \
+ typeof(prefix) strcmp_prefix =
prefix; \
+ strcmp_prefix_ret
= \
+ strncmp(str,
strcmp_prefix, \
+
strlen(strcmp_prefix)); \
+ }
\
+
strcmp_prefix_ret; \
+ })
+
/*
* Include machine specific inline routines
*/
Re: x86/sgx: uapi change proposal
> On Dec 19, 2018, at 6:45 AM, Sean Christopherson
> wrote:
>
>> On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
> I agree with Jethro, passing the enclave_fd as a param is obnoxious.
> And it means the user needs to open /dev/sgx to do anything with an
> enclave fd, e.g. the enclave fd might be passed to a builder thread,
> it shouldn't also need the device fd.
>
> E.g.:
>
>sgx_fd = open("/dev/sgx", O_RDWR);
>BUG_ON(sgx_fd < 0);
>
>enclave_fd = ioctl(sgx_fd, SGX_ENCLAVE_CREATE, );
>BUG_ON(enclave_fd < 0);
>
>ret = ioctl(enclave_fd, SGX_ENCLAVE_ADD_PAGE, );
>BUG_ON(ret);
>
>...
>
>ret = ioctl(enclave_fd, SGX_ENCLAVE_INIT, );
>BUG_ON(ret);
>
>...
>
>close(enclave_fd);
>close(sgx_fd);
>
>
> Take a look at virt/kvm/kvm_main.c to see how KVM manages anon inodes
> and ioctls for VMs and vCPUs.
Can one of you explain why SGX_ENCLAVE_CREATE is better than just
opening a new instance of /dev/sgx for each encalve?
