* [PATCH rdma-next 3/6] IB/uverbs: Add support for Vxlan protocol
From: Leon Romanovsky @ 2016-11-14 17:04 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Maor Gottlieb,
Moses Reuben
In-Reply-To: <1479143092-11723-1-git-send-email-leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Add ib_uverbs_flow_spec_tunnel to define the rule to match Vxlan,
the type, size, reserved fields are identical to rest of the protocols,
and are used to identify the spec.
The tunnel id is the vni value of the Vxlan protocol, and it is used
as part of the steering rule, it is limited by the mask.
The steering rule configured on the hardware does a match
according to vni and other protocols.
In the same way as rest of the protocols that we match,
the uniq field's of each protocol are represented on
the val and the mask.
Signed-off-by: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Maor Gottlieb <maorg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
include/uapi/rdma/ib_user_verbs.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 25225eb..90ba5e8 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -908,6 +908,23 @@ struct ib_uverbs_flow_spec_ipv6 {
struct ib_uverbs_flow_ipv6_filter mask;
};
+struct ib_uverbs_flow_tunnel_filter {
+ __be32 tunnel_id;
+};
+
+struct ib_uverbs_flow_spec_tunnel {
+ union {
+ struct ib_uverbs_flow_spec_hdr hdr;
+ struct {
+ __u32 type;
+ __u16 size;
+ __u16 reserved;
+ };
+ };
+ struct ib_uverbs_flow_tunnel_filter val;
+ struct ib_uverbs_flow_tunnel_filter mask;
+};
+
struct ib_uverbs_flow_attr {
__u32 type;
__u16 size;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next 2/6] IB/core: Align structure ib_flow_spec_type
From: Leon Romanovsky @ 2016-11-14 17:04 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Maor Gottlieb,
Moses Reuben
In-Reply-To: <1479143092-11723-1-git-send-email-leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Aligned the structure ib_flow_spec_type indentation,
after adding a new definition.
Signed-off-by: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Maor Gottlieb <maorg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
include/rdma/ib_verbs.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9dd8309..81c5c80 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1592,14 +1592,14 @@ enum ib_flow_attr_type {
/* Supported steering header types */
enum ib_flow_spec_type {
/* L2 headers*/
- IB_FLOW_SPEC_ETH = 0x20,
- IB_FLOW_SPEC_IB = 0x22,
+ IB_FLOW_SPEC_ETH = 0x20,
+ IB_FLOW_SPEC_IB = 0x22,
/* L3 header*/
- IB_FLOW_SPEC_IPV4 = 0x30,
- IB_FLOW_SPEC_IPV6 = 0x31,
+ IB_FLOW_SPEC_IPV4 = 0x30,
+ IB_FLOW_SPEC_IPV6 = 0x31,
/* L4 headers*/
- IB_FLOW_SPEC_TCP = 0x40,
- IB_FLOW_SPEC_UDP = 0x41,
+ IB_FLOW_SPEC_TCP = 0x40,
+ IB_FLOW_SPEC_UDP = 0x41,
IB_FLOW_SPEC_VXLAN_TUNNEL = 0x50,
};
#define IB_FLOW_SPEC_LAYER_MASK 0xF0
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next 1/6] IB/core: Add flow spec tunneling support
From: Leon Romanovsky @ 2016-11-14 17:04 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Maor Gottlieb,
Moses Reuben
In-Reply-To: <1479143092-11723-1-git-send-email-leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
In order to support tunneling, that can be used by the QP,
both struct ib_flow_spec_tunnel and struct ib_flow_tunnel_filter can be
used to more IP or UDP based tunneling protocols (e.g NVGRE, GRE, etc).
IB_FLOW_SPEC_VXLAN_TUNNEL type flow specification is added to use this
functionality and match specific Vxlan packets.
In similar to IPv6, we check overflow of the vni value by
comparing with the maximum size.
Signed-off-by: Moses Reuben <mosesr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Maor Gottlieb <maorg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/infiniband/core/uverbs_cmd.c | 15 +++++++++++++++
include/rdma/ib_verbs.h | 19 ++++++++++++++++++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index cb3f515a..561010a 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3175,6 +3175,21 @@ static int kern_spec_to_ib_spec(struct ib_uverbs_flow_spec *kern_spec,
memcpy(&ib_spec->tcp_udp.val, kern_spec_val, actual_filter_sz);
memcpy(&ib_spec->tcp_udp.mask, kern_spec_mask, actual_filter_sz);
break;
+ case IB_FLOW_SPEC_VXLAN_TUNNEL:
+ ib_filter_sz = offsetof(struct ib_flow_tunnel_filter, real_sz);
+ actual_filter_sz = spec_filter_size(kern_spec_mask,
+ kern_filter_sz,
+ ib_filter_sz);
+ if (actual_filter_sz <= 0)
+ return -EINVAL;
+ ib_spec->tunnel.size = sizeof(struct ib_flow_spec_tunnel);
+ memcpy(&ib_spec->tunnel.val, kern_spec_val, actual_filter_sz);
+ memcpy(&ib_spec->tunnel.mask, kern_spec_mask, actual_filter_sz);
+
+ if ((ntohl(ib_spec->tunnel.mask.tunnel_id)) >= BIT(24) ||
+ (ntohl(ib_spec->tunnel.val.tunnel_id)) >= BIT(24))
+ return -EINVAL;
+ break;
default:
return -EINVAL;
}
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 5ad43a4..9dd8309 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1599,7 +1599,8 @@ enum ib_flow_spec_type {
IB_FLOW_SPEC_IPV6 = 0x31,
/* L4 headers*/
IB_FLOW_SPEC_TCP = 0x40,
- IB_FLOW_SPEC_UDP = 0x41
+ IB_FLOW_SPEC_UDP = 0x41,
+ IB_FLOW_SPEC_VXLAN_TUNNEL = 0x50,
};
#define IB_FLOW_SPEC_LAYER_MASK 0xF0
#define IB_FLOW_SPEC_SUPPORT_LAYERS 4
@@ -1707,6 +1708,21 @@ struct ib_flow_spec_tcp_udp {
struct ib_flow_tcp_udp_filter mask;
};
+struct ib_flow_tunnel_filter {
+ __be32 tunnel_id;
+ u8 real_sz[0];
+};
+
+/* ib_flow_spec_tunnel describes the Vxlan tunnel
+ * the tunnel_id from val has the vni value
+ */
+struct ib_flow_spec_tunnel {
+ enum ib_flow_spec_type type;
+ u16 size;
+ struct ib_flow_tunnel_filter val;
+ struct ib_flow_tunnel_filter mask;
+};
+
union ib_flow_spec {
struct {
enum ib_flow_spec_type type;
@@ -1717,6 +1733,7 @@ union ib_flow_spec {
struct ib_flow_spec_ipv4 ipv4;
struct ib_flow_spec_tcp_udp tcp_udp;
struct ib_flow_spec_ipv6 ipv6;
+ struct ib_flow_spec_tunnel tunnel;
};
struct ib_flow_attr {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next 0/6] Add support for Vxlan protocol for the steering rules
From: Leon Romanovsky @ 2016-11-14 17:04 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky, Maor Gottlieb
From: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Virtual Extensible LAN - Vxlan is a proposed encapsulation protocol for
running an overlay network on existing Layer 3 infrastructure. An
overlay network is a virtual network that is built on top of existing
network Layer 2 and Layer 3 technologies to support elastic COMPUTE
architectures. Vxlan will make it easier for network engineers to scale
out a cloud computing environment while logically isolating cloud apps
and tenants.
This patchset introduces support Vxlan steering rules to IB/core and
mlx5 devices implementation. The application will be able to send
packet with Vxlan tunneling, and configure a steering rule to receive
the stream from the rule to the QP.
The rule will contain inner and outer parts for the inner and outer
protocol header respectively. The matching is based on the rule
specification and it includes the Vxlan header itself, so application
will be able to send several Vxlan streams with a new vni for each stream.
In order to steer traffic according to a Vxlan tunnel ID, there is a need to
use the ibv_cmd_create_flow call. At the end of the struct, the application
should append several specs for each feature.
The number of specifications to add is 4. Use the first as the Vxlan
spec (tunnel), which is described below. The following specifications to
add are the L2, L3, and L4 specs.
There is an option to mask a range of tunnel IDs to be steered by using
the filler mask, This following example provides the ibv_flow_tunnel_filter
struct definition:
struct ibv_flow_tunnel_filter {
uint32_t tunnel_id;
};
This following example specifies the Vxlan tunnel definition:
struct ibv_flow_spec_tunnel {
enum ibv_flow_spec_type type;
uint16_t size;
struct ibv_flow_tunnel_filter val;
struct ibv_flow_tunnel_filter mask;
};
Where:
* type - Specifies that there is a need to use IBV_FLOW_SPEC_VXLAN_TUNNEL
to define the spec as an Vxlan spec.
* size - Identifies the size of the ibv_kern_spec_tunnel.
* tunnel_id: Indicates that the tunnel ID as in the Vxlan header.
Thanks,
Mosses and Leon.
Available in the "topic/vxlan" topic branch of this git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git
Or for browsing:
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=topic/vxlan
CC: Maor Gottlieb <maorg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Moses Reuben (6):
IB/core: Add flow spec tunneling support
IB/core: Align structure ib_flow_spec_type
IB/uverbs: Add support for Vxlan protocol
IB/mlx5: Support Vxlan tunneling specification
IB/core: Introduce inner flow steering
IB/mlx5: Add support to match inner packet fields
drivers/infiniband/core/uverbs_cmd.c | 19 ++++-
drivers/infiniband/hw/mlx5/main.c | 142 ++++++++++++++++++++++-------------
include/rdma/ib_verbs.h | 44 +++++++----
include/uapi/rdma/ib_user_verbs.h | 17 +++++
4 files changed, 155 insertions(+), 67 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 02/14] SoundWire: Add SoundWire stream documentation
From: Charles Keepax @ 2016-11-14 17:04 UTC (permalink / raw)
To: Pierre-Louis Bossart
Cc: Hardik Shah, alsa-devel, linux-kernel, tiwai, broonie, lgirdwood,
plai, patches.audio, Sanyog Kale
In-Reply-To: <b0d67cc6-f7fb-ea61-29b3-02a7f7c0aac3@linux.intel.com>
On Mon, Nov 14, 2016 at 10:50:10AM -0600, Pierre-Louis Bossart wrote:
>
> >>+SoundWire stream states
> >>+=======================
> >>+Below figure shows the SoundWire stream states and possible state
> >>+transition diagram.
> >>+
> >>+|--------------| |-------------| |--------------| |--------------|
> >>+| ALLOC |---->| CONFIG |---->| PREPARE |---->| ENABLE |
> >>+| STATE | | STATE | | STATE | | STATE |
> >>+|--------------| |-------------| |--------------| |--------------|
> >>+ ^ |
> >>+ | |
> >>+ | |
> >>+ | |
> >>+ | \/
> >>+ |--------------| |--------------| |--------------|
> >>+ | RELEASE |<--------------------| DEPREPARE |<----| DISABLE |
> >>+ | STATE | | STATE | | STATE |
> >>+ |--------------| |--------------| |--------------|
> >>+
> >
> >One minor comment, this looks very similar to the clock
> >frameworks state model, but the clock framework calls it
> >unprepare would there be some milage in aligning to?
>
> The SoundWire spec uses de-prepare, e.g. "De-prepare_Finished"
> I'd rather stick to the wording between a spec and the implementation of
> said spec, rather than introduce a term/concept from an unrelated framework.
> >
Cool we should leave that as is then :-)
> >>+4. Once all the new values are programmed, bus initiates switch to
> >>+alternate bank. Once switch is successful, the port channels enabled on
> >>+previous bank for already active streams are disabled.
>
> This last sentence makes no sense in this context, probably a copy/paste
> that shouldn't be there. The previously active streams remain active in this
> prepare step.
>
> >>+
> >>+5. Ports of Master and Slave for current stream are prepared.
> >>+
> >>+After all above operations are successful, stream state is set to
> >>+SDW_STATE_STRM_PREPARE.
> >>+
> >>+
> >>+SDW_STATE_STRM_ENABLE: Enable state of stream. Operations performed
> >>+before entering in this state:
> >>+1. All the values computed in SDW_STATE_STRM_PREPARE state are
> >>+programmed in alternate bank (bank currently unused). It includes
> >>+programming of already active streams as well.
> >>+
> >>+2. All the Master and Slave port channels for the current stream are
> >>+enabled on alternate bank (bank currently unused).
> >>+
> >
> >This could probably use a little more explaination to show how it
> >differs from step 3/4 in PREPARE, as it looks like all the
> >computed values where applied there. I imagine this is just my lack
> >of understanding rather than an actual issue but even looking at
> >the code I am having a little difficulty tying up these two.
>
> Yes, see above there was an extra sentence that isn't right.
>
> >
> >sdw_prepare_op
> >- sdw_compute_params (prepare step 1/2)
> >- sdw_program_params (prepare step 3)
> >- sdw_update_bus_params (prepare step 4)
> >
> >sdw_enable_op
> >- sdw_program_params (enable step 1)
> >- sdw_update_bus_params (enable step 2)
> >
> >It looks like the params are still basically the same as they
> >were when we called sdw_program_params in prepare.
>
> The parameters are the same except for the channel-enable flags which are
> only programmed and activated via a bank switch in the enable step.
Ah ok that is what is getting pushed out there, thanks for
explaining.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Rob Herring @ 2016-11-14 17:04 UTC (permalink / raw)
To: Hao Zhang
Cc: maxime.ripard, wens, mark.rutland, vinod.koul, devicetree,
linux-kernel, dmaengine, linux-arm-kernel
In-Reply-To: <20161107181457.GA3619@arx12>
On Tue, Nov 08, 2016 at 02:14:57AM +0800, Hao Zhang wrote:
> This adds documentation of the sun50i a64 dma binding compatible.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Rob Herring @ 2016-11-14 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107181457.GA3619@arx12>
On Tue, Nov 08, 2016 at 02:14:57AM +0800, Hao Zhang wrote:
> This adds documentation of the sun50i a64 dma binding compatible.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache
From: Vlastimil Babka @ 2016-11-14 17:04 UTC (permalink / raw)
To: E V
Cc: Andrew Morton, bugzilla-daemon, linux-mm, Michal Hocko,
linux-btrfs, Kirill A. Shutemov
In-Reply-To: <CAJtFHUQgkvFaPdyRcoiV-m5hynDGo2qXfMXzZvGahoWp2LL_KA@mail.gmail.com>
On 11/14/2016 02:27 PM, E V wrote:
> System is an intel dual socket Xeon E5620, 7500/5520/5500/X58 ICH10
> family according to lspci. Anyways 4.8.4 OOM'd while I was gone. I'll
> download the current 4.9rc and reboot, but in the mean time here's
> xxd, vmstat & kern.log output:
> 8532039 0000000000000000
Hmm this would suggest that the memory is mostly free. But not according
to vmstat. Is it possible you mistakenly provided the xxd from a fresh
boot, but vmstat from after the OOM?
But sure, a page_count() of zero is a reason why __isolate_lru_page()
would fail due to its get_page_unless_zero(). The question is then how
could it drop to zero without being freed at the same time, as
put_page() does.
I was going to suspect commit 83929372f6 and a page_ref_sub() it adds to
delete_from_page_cache(), but that's since 4.8 and you mention problems
since 4.7.
Anyway it might be worth enabling CONFIG_DEBUG_VM as the relevant code
usually has VM_BUG_ONs.
Vlastimil
> 9324 0100000000000000
> 2226 0200000000000000
> 405 0300000000000000
> 80 0400000000000000
> 34 0500000000000000
> 48 0600000000000000
> 17 0700000000000000
> 17 0800000000000000
> 32 0900000000000000
> 19 0a00000000000000
> 1 0c00000000000000
> 1 0d00000000000000
> 1 0e00000000000000
> 12 1000000000000000
> 8 1100000000000000
> 32 1200000000000000
> 10 1300000000000000
> 2 1400000000000000
> 11 1500000000000000
> 12 1600000000000000
> 7 1700000000000000
> 3 1800000000000000
> 5 1900000000000000
> 6 1a00000000000000
> 11 1b00000000000000
> 22 1c00000000000000
> 3 1d00000000000000
> 19 1e00000000000000
> 21 1f00000000000000
> 18 2000000000000000
> 28 2100000000000000
> 40 2200000000000000
> 38 2300000000000000
> 85 2400000000000000
> 59 2500000000000000
> 40520 81ffffffffffffff
>
> /proc/vmstat:
> nr_free_pages 60965
> nr_zone_inactive_anon 4646
> nr_zone_active_anon 3265
> nr_zone_inactive_file 633882
> nr_zone_active_file 7017458
> nr_zone_unevictable 0
> nr_zone_write_pending 0
> nr_mlock 0
> nr_slab_reclaimable 299205
> nr_slab_unreclaimable 195497
> nr_page_table_pages 935
> nr_kernel_stack 4976
> nr_bounce 0
> numa_hit 3577063288
> numa_miss 541393191
> numa_foreign 541393191
> numa_interleave 19415
> numa_local 3577063288
> numa_other 0
> nr_free_cma 0
> nr_inactive_anon 4646
> nr_active_anon 3265
> nr_inactive_file 633882
> nr_active_file 7017458
> nr_unevictable 0
> nr_isolated_anon 0
> nr_isolated_file 0
> nr_pages_scanned 0
> workingset_refault 42685891
> workingset_activate 15247281
> workingset_nodereclaim 26375216
> nr_anon_pages 5067
> nr_mapped 5630
> nr_file_pages 7654746
> nr_dirty 0
> nr_writeback 0
> nr_writeback_temp 0
> nr_shmem 2504
> nr_shmem_hugepages 0
> nr_shmem_pmdmapped 0
> nr_anon_transparent_hugepages 0
> nr_unstable 0
> nr_vmscan_write 5243750485
> nr_vmscan_immediate_reclaim 4207633857
> nr_dirtied 1839143430
> nr_written 1832626107
> nr_dirty_threshold 1147728
> nr_dirty_background_threshold 151410
> pgpgin 166731189
> pgpgout 7328142335
> pswpin 98608
> pswpout 117794
> pgalloc_dma 29504
> pgalloc_dma32 1006726216
> pgalloc_normal 5275218188
> pgalloc_movable 0
> allocstall_dma 0
> allocstall_dma32 0
> allocstall_normal 36461
> allocstall_movable 5867
> pgskip_dma 0
> pgskip_dma32 0
> pgskip_normal 6417890
> pgskip_movable 0
> pgfree 6309223401
> pgactivate 35076483
> pgdeactivate 63556974
> pgfault 35753842
> pgmajfault 69126
> pglazyfreed 0
> pgrefill 70008598
> pgsteal_kswapd 3567289713
> pgsteal_direct 5878057
> pgscan_kswapd 9059309872
> pgscan_direct 4239367903
> pgscan_direct_throttle 0
> zone_reclaim_failed 0
> pginodesteal 102916
> slabs_scanned 460790262
> kswapd_inodesteal 9130243
> kswapd_low_wmark_hit_quickly 10634373
> kswapd_high_wmark_hit_quickly 7348173
> pageoutrun 18349115
> pgrotated 16291322
> drop_pagecache 0
> drop_slab 0
> pgmigrate_success 18912908
> pgmigrate_fail 63382146
> compact_migrate_scanned 2986269789
> compact_free_scanned 190451505123
> compact_isolated 109549437
> compact_stall 3544
> compact_fail 8
> compact_success 3536
> compact_daemon_wake 1403515
> htlb_buddy_alloc_success 0
> htlb_buddy_alloc_fail 0
> unevictable_pgs_culled 12473
> unevictable_pgs_scanned 0
> unevictable_pgs_rescued 11979
> unevictable_pgs_mlocked 14556
> unevictable_pgs_munlocked 14556
> unevictable_pgs_cleared 0
> unevictable_pgs_stranded 0
> thp_fault_alloc 0
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_file_alloc 0
> thp_file_mapped 0
> thp_split_page 0
> thp_split_page_failed 0
> thp_deferred_split_page 0
> thp_split_pmd 0
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
>
> kern.log OOM message:
> [737778.724194] snmpd invoked oom-killer:
> gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
> [737778.724246] snmpd cpuset=/ mems_allowed=0-1
> [737778.724278] CPU: 15 PID: 2976 Comm: snmpd Tainted: G W I 4.8.4 #1
> [737778.724352] 0000000000000000 ffffffff81292069 ffff88041e043c48
> ffff88041e043c48
> [737778.724403] ffffffff8118d1f6 ffff88041dd70fc0 ffff88041e043c48
> 000000000136236f
> [737778.724454] ffffffff8170e11e 0000000000000001 ffffffff8112a700
> 000000000000030f
> [737778.724505] Call Trace:
> [737778.724533] [<ffffffff81292069>] ? dump_stack+0x46/0x5d
> [737778.727077] [<ffffffff8118d1f6>] ? dump_header.isra.16+0x56/0x185
> [737778.727108] [<ffffffff8112a700>] ? oom_kill_process+0x210/0x3c0
> [737778.727136] [<ffffffff8112ac4b>] ? out_of_memory+0x34b/0x420
> [737778.727165] [<ffffffff8112fcca>] ? __alloc_pages_nodemask+0xd9a/0xde0
> [737778.727195] [<ffffffff811768e1>] ? alloc_pages_vma+0xc1/0x240
> [737778.727223] [<ffffffff81126512>] ? pagecache_get_page+0x22/0x230
> [737778.727253] [<ffffffff81169f44>] ? __read_swap_cache_async+0x104/0x180
> [737778.727282] [<ffffffff81169fcf>] ? read_swap_cache_async+0xf/0x30
> [737778.727311] [<ffffffff8116a0dc>] ? swapin_readahead+0xec/0x1a0
> [737778.727340] [<ffffffff81156270>] ? do_swap_page+0x420/0x5c0
> [737778.727369] [<ffffffff813f36d8>] ? SYSC_recvfrom+0xa8/0x110
> [737778.727397] [<ffffffff81157a39>] ? handle_mm_fault+0x629/0xe30
> [737778.727426] [<ffffffff81048fc5>] ? __do_page_fault+0x1b5/0x480
> [737778.727456] [<ffffffff814fbaa2>] ? page_fault+0x22/0x30
> [737778.727497] Mem-Info:
> [737778.727524] active_anon:24 inactive_anon:49 isolated_anon:0
> [737778.727524] active_file:6920154 inactive_file:798043 isolated_file:576
> [737778.727524] unevictable:0 dirty:800528 writeback:1307 unstable:0
> [737778.727524] slab_reclaimable:264367 slab_unreclaimable:193348
> [737778.727524] mapped:4063 shmem:0 pagetables:1719 bounce:0
> [737778.727524] free:39225 free_pcp:47 free_cma:0
> [737778.727677] Node 0 active_anon:16kB inactive_anon:76kB
> active_file:14249324kB inactive_file:1296908kB unevictable:0kB
> isolated(anon):0kB isolated(file):1920kB mapped:10432kB
> dirty:1308528kB writeback:0kB shmem:0kB shmem_thp: 0kB
> shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
> pages_scanned:23557303 all_unreclaimable? yes
> [737778.727806] Node 1 active_anon:80kB inactive_anon:120kB
> active_file:13431292kB inactive_file:1895264kB unevictable:0kB
> isolated(anon):0kB isolated(file):384kB mapped:5820kB dirty:1893584kB
> writeback:5228kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB
> anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:25598673
> all_unreclaimable? yes
> [737778.727930] Node 0 Normal free:44864kB min:45192kB low:61736kB
> high:78280kB active_anon:16kB inactive_anon:76kB
> active_file:14249324kB inactive_file:1296908kB unevictable:0kB
> writepending:1308528kB present:16777216kB managed:16544856kB
> mlocked:0kB slab_reclaimable:562644kB slab_unreclaimable:317504kB
> kernel_stack:3840kB pagetables:3672kB bounce:0kB free_pcp:20kB
> local_pcp:0kB free_cma:0kB
> [737778.728066] lowmem_reserve[]: 0 0 0 0
> [737778.728100] Node 1 DMA free:15896kB min:40kB low:52kB high:64kB
> active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
> unevictable:0kB writepending:0kB present:15996kB managed:15896kB
> mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
> kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
> free_cma:0kB
> [737778.728228] lowmem_reserve[]: 0 3216 16044 16044
> [737778.728263] Node 1 DMA32 free:60300kB min:8996kB low:12288kB
> high:15580kB active_anon:4kB inactive_anon:4kB active_file:2660988kB
> inactive_file:474956kB unevictable:0kB writepending:475116kB
> present:3378660kB managed:3304720kB mlocked:0kB
> slab_reclaimable:83612kB slab_unreclaimable:16668kB kernel_stack:320kB
> pagetables:16kB bounce:0kB free_pcp:4kB local_pcp:4kB free_cma:0kB
> [737778.728397] lowmem_reserve[]: 0 0 12827 12827
> [737778.728431] Node 1 Normal free:35840kB min:35876kB low:49008kB
> high:62140kB active_anon:76kB inactive_anon:116kB
> active_file:10770304kB inactive_file:1420308kB unevictable:0kB
> writepending:1423696kB present:13369344kB managed:13135424kB
> mlocked:0kB slab_reclaimable:411212kB slab_unreclaimable:439220kB
> kernel_stack:2864kB pagetables:3188kB bounce:0kB free_pcp:164kB
> local_pcp:36kB free_cma:0kB
> [737778.728568] lowmem_reserve[]: 0 0 0 0
> [737778.728601] Node 0 Normal: 11208*4kB (UME) 4*8kB (U) 0*16kB 0*32kB
> 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44864kB
> [737778.728686] Node 1 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB
> (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB
> (M) = 15896kB
> [737778.728786] Node 1 DMA32: 11759*4kB (UME) 1658*8kB (UM) 0*16kB
> 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
> 60300kB
> [737778.728875] Node 1 Normal: 7984*4kB (UME) 470*8kB (UME) 3*16kB (U)
> 3*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
> = 35840kB
> [737778.728973] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [737778.729019] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [737778.729065] Node 1 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [737778.729111] Node 1 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [737778.729156] 7718841 total pagecache pages
> [737778.729179] 68 pages in swap cache
> [737778.729202] Swap cache stats: add 193888, delete 193820, find 160188/213014
> [737778.729231] Free swap = 48045076kB
> [737778.729254] Total swap = 48300028kB
> [737778.729277] 8385304 pages RAM
> [737778.729299] 0 pages HighMem/MovableOnly
> [737778.729322] 135080 pages reserved
> [737778.729344] 0 pages hwpoisoned
> [737778.729365] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds
> swapents oom_score_adj name
> [737778.729417] [ 1927] 0 1927 9941 447 22 3
> 299 -1000 systemd-udevd
> [737778.729465] [ 2812] 0 2812 9289 412 23 4
> 161 0 rpcbind
> [737778.729512] [ 2836] 102 2836 9320 414 23 3
> 151 0 rpc.statd
> [737778.729560] [ 2851] 104 2851 162257 276 75 3
> 7489 0 apt-cacher-ng
> [737778.729608] [ 2856] 0 2856 13796 345 31 3
> 167 -1000 sshd
> [737778.729655] [ 2857] 0 2857 64668 504 27 4
> 355 0 rsyslogd
> [737778.729702] [ 2858] 0 2858 6876 518 18 3
> 83 0 cron
> [737778.729748] [ 2859] 0 2859 4756 360 14 3
> 44 0 atd
> [737778.729795] [ 2860] 0 2860 7059 523 18 3
> 591 0 smartd
> [737778.729842] [ 2864] 0 2864 7082 559 19 4
> 96 0 systemd-logind
> [737778.729890] [ 2865] 106 2865 10563 528 24 3
> 110 -900 dbus-daemon
> [737778.729938] [ 2925] 0 2925 3604 421 12 3
> 38 0 agetty
> [737778.729985] [ 2974] 0 2974 4852 365 13 3
> 73 0 irqbalance
> [737778.730032] [ 2976] 105 2976 14299 496 29 3
> 1534 0 snmpd
> [737778.730078] [ 2992] 0 2992 3180 227 11 3
> 38 0 mcelog
> [737778.730125] [ 3095] 0 3095 26571 344 43 3
> 259 0 sfcbd
> [737778.730172] [ 3172] 0 3172 20392 261 40 3
> 236 0 sfcbd
> [737778.730219] [ 3248] 0 3248 22441 0 41 3
> 238 0 sfcbd
> [737778.730265] [ 3249] 0 3249 39376 155 44 3
> 357 0 sfcbd
> [737778.730312] [ 3450] 0 3450 39377 104 44 3
> 244 0 sfcbd
> [737778.730359] [ 3467] 0 3467 58324 301 46 3
> 284 0 sfcbd
> [737778.730405] [ 3548] 0 3548 262686 643 66 4
> 4097 0 dsm_sa_datamgrd
> [737778.730453] [ 3563] 101 3563 13312 403 29 3
> 162 0 exim4
> [737778.730499] [ 3576] 107 3576 7293 493 19 3
> 148 0 ntpd
> [737778.730546] [ 3585] 0 3585 61531 577 117 3
> 496 0 winbindd
> [737778.730593] [ 3586] 0 3586 61531 578 118 3
> 512 0 winbindd
> [737778.730640] [ 3651] 0 3651 48584 566 36 3
> 487 0 dsm_sa_eventmgr
> [737778.730688] [ 3674] 0 3674 99593 576 47 3
> 1402 0 dsm_sa_snmpd
> [737778.730736] [ 3717] 0 3717 7923 285 18 3
> 115 0 dsm_om_connsvcd
> [737778.730784] [ 3718] 0 3718 740234 1744 202 7
> 30685 0 dsm_om_connsvcd
> [737778.730832] [ 3736] 0 3736 178651 0 55 3
> 3789 0 dsm_sa_datamgrd
> [737778.730880] [ 4056] 0 4056 26472 498 57 3
> 252 0 sshd
> [737778.730926] [ 4060] 1000 4060 8973 501 23 3
> 184 0 systemd
> [737778.730973] [ 4061] 1000 4061 15702 0 34 4
> 612 0 (sd-pam)
> [737778.731020] [ 4063] 1000 4063 26472 158 54 3
> 260 0 sshd
> [737778.731067] [ 4064] 1000 4064 6041 739 16 3
> 686 0 bash
> [737778.731113] [ 4083] 1000 4083 16853 493 37 3
> 128 0 su
> [737778.731160] [ 4084] 0 4084 5501 756 15 3
> 160 0 bash
> [737778.731207] [15150] 0 15150 3309 678 10 3
> 57 0 run_mirror.sh
> [737778.731256] [24296] 0 24296 1450 139 8 3
> 23 0 flock
> [737778.731302] [24297] 0 24297 9576 622 22 3
> 3990 0 rsync
> [737778.731349] [24298] 0 24298 7552 541 18 3
> 1073 0 rsync
> [737778.731395] [24299] 0 24299 9522 401 22 3
> 2416 0 rsync
> [737778.731445] [25910] 0 25910 10257 522 23 3
> 81 0 systemd-journal
> [737778.731494] [25940] 0 25940 16365 617 37 3
> 126 0 cron
> [737778.731540] Out of memory: Kill process 3718 (dsm_om_connsvcd)
> score 1 or sacrifice child
> [737778.731644] Killed process 3718 (dsm_om_connsvcd)
> total-vm:2960936kB, anon-rss:0kB, file-rss:6976kB, shmem-rss:0kB
> [737778.768375] oom_reaper: reaped process 3718 (dsm_om_connsvcd), now
> anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
>
> On Fri, Nov 4, 2016 at 5:00 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
>> On 11/04/2016 03:13 PM, E V wrote:
>>> After the system panic'd yesterday I booted back into 4.8.4 and
>>> restarted the rsync's. I'm away on vacation next week, so when I get
>>> back I'll get rc4 or rc5 and try again. In the mean time here's data
>>> from the system running 4.8.4 without problems for about a day. I'm
>>> not familiar with xxd and didn't see a -e option, so used -E:
>>> xxd -E -g8 -c8 /proc/kpagecount | cut -d" " -f2 | sort | uniq -c
>>> 8258633 0000000000000000
>>> 216440 0100000000000000
>>
>> The lack of -e means it's big endian, which is not a big issue. So here
>> most of memory is free, some pages have just one pin, and only
>> relatively few have more. The vmstats also doesn't show anything bad, so
>> we'll have to wait if something appears within the week, or after you
>> try 4.9 again. Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache
From: Vlastimil Babka @ 2016-11-14 17:04 UTC (permalink / raw)
To: E V
Cc: Andrew Morton, bugzilla-daemon, linux-mm, Michal Hocko,
linux-btrfs, Kirill A. Shutemov
In-Reply-To: <CAJtFHUQgkvFaPdyRcoiV-m5hynDGo2qXfMXzZvGahoWp2LL_KA@mail.gmail.com>
On 11/14/2016 02:27 PM, E V wrote:
> System is an intel dual socket Xeon E5620, 7500/5520/5500/X58 ICH10
> family according to lspci. Anyways 4.8.4 OOM'd while I was gone. I'll
> download the current 4.9rc and reboot, but in the mean time here's
> xxd, vmstat & kern.log output:
> 8532039 0000000000000000
Hmm this would suggest that the memory is mostly free. But not according
to vmstat. Is it possible you mistakenly provided the xxd from a fresh
boot, but vmstat from after the OOM?
But sure, a page_count() of zero is a reason why __isolate_lru_page()
would fail due to its get_page_unless_zero(). The question is then how
could it drop to zero without being freed at the same time, as
put_page() does.
I was going to suspect commit 83929372f6 and a page_ref_sub() it adds to
delete_from_page_cache(), but that's since 4.8 and you mention problems
since 4.7.
Anyway it might be worth enabling CONFIG_DEBUG_VM as the relevant code
usually has VM_BUG_ONs.
Vlastimil
> 9324 0100000000000000
> 2226 0200000000000000
> 405 0300000000000000
> 80 0400000000000000
> 34 0500000000000000
> 48 0600000000000000
> 17 0700000000000000
> 17 0800000000000000
> 32 0900000000000000
> 19 0a00000000000000
> 1 0c00000000000000
> 1 0d00000000000000
> 1 0e00000000000000
> 12 1000000000000000
> 8 1100000000000000
> 32 1200000000000000
> 10 1300000000000000
> 2 1400000000000000
> 11 1500000000000000
> 12 1600000000000000
> 7 1700000000000000
> 3 1800000000000000
> 5 1900000000000000
> 6 1a00000000000000
> 11 1b00000000000000
> 22 1c00000000000000
> 3 1d00000000000000
> 19 1e00000000000000
> 21 1f00000000000000
> 18 2000000000000000
> 28 2100000000000000
> 40 2200000000000000
> 38 2300000000000000
> 85 2400000000000000
> 59 2500000000000000
> 40520 81ffffffffffffff
>
> /proc/vmstat:
> nr_free_pages 60965
> nr_zone_inactive_anon 4646
> nr_zone_active_anon 3265
> nr_zone_inactive_file 633882
> nr_zone_active_file 7017458
> nr_zone_unevictable 0
> nr_zone_write_pending 0
> nr_mlock 0
> nr_slab_reclaimable 299205
> nr_slab_unreclaimable 195497
> nr_page_table_pages 935
> nr_kernel_stack 4976
> nr_bounce 0
> numa_hit 3577063288
> numa_miss 541393191
> numa_foreign 541393191
> numa_interleave 19415
> numa_local 3577063288
> numa_other 0
> nr_free_cma 0
> nr_inactive_anon 4646
> nr_active_anon 3265
> nr_inactive_file 633882
> nr_active_file 7017458
> nr_unevictable 0
> nr_isolated_anon 0
> nr_isolated_file 0
> nr_pages_scanned 0
> workingset_refault 42685891
> workingset_activate 15247281
> workingset_nodereclaim 26375216
> nr_anon_pages 5067
> nr_mapped 5630
> nr_file_pages 7654746
> nr_dirty 0
> nr_writeback 0
> nr_writeback_temp 0
> nr_shmem 2504
> nr_shmem_hugepages 0
> nr_shmem_pmdmapped 0
> nr_anon_transparent_hugepages 0
> nr_unstable 0
> nr_vmscan_write 5243750485
> nr_vmscan_immediate_reclaim 4207633857
> nr_dirtied 1839143430
> nr_written 1832626107
> nr_dirty_threshold 1147728
> nr_dirty_background_threshold 151410
> pgpgin 166731189
> pgpgout 7328142335
> pswpin 98608
> pswpout 117794
> pgalloc_dma 29504
> pgalloc_dma32 1006726216
> pgalloc_normal 5275218188
> pgalloc_movable 0
> allocstall_dma 0
> allocstall_dma32 0
> allocstall_normal 36461
> allocstall_movable 5867
> pgskip_dma 0
> pgskip_dma32 0
> pgskip_normal 6417890
> pgskip_movable 0
> pgfree 6309223401
> pgactivate 35076483
> pgdeactivate 63556974
> pgfault 35753842
> pgmajfault 69126
> pglazyfreed 0
> pgrefill 70008598
> pgsteal_kswapd 3567289713
> pgsteal_direct 5878057
> pgscan_kswapd 9059309872
> pgscan_direct 4239367903
> pgscan_direct_throttle 0
> zone_reclaim_failed 0
> pginodesteal 102916
> slabs_scanned 460790262
> kswapd_inodesteal 9130243
> kswapd_low_wmark_hit_quickly 10634373
> kswapd_high_wmark_hit_quickly 7348173
> pageoutrun 18349115
> pgrotated 16291322
> drop_pagecache 0
> drop_slab 0
> pgmigrate_success 18912908
> pgmigrate_fail 63382146
> compact_migrate_scanned 2986269789
> compact_free_scanned 190451505123
> compact_isolated 109549437
> compact_stall 3544
> compact_fail 8
> compact_success 3536
> compact_daemon_wake 1403515
> htlb_buddy_alloc_success 0
> htlb_buddy_alloc_fail 0
> unevictable_pgs_culled 12473
> unevictable_pgs_scanned 0
> unevictable_pgs_rescued 11979
> unevictable_pgs_mlocked 14556
> unevictable_pgs_munlocked 14556
> unevictable_pgs_cleared 0
> unevictable_pgs_stranded 0
> thp_fault_alloc 0
> thp_fault_fallback 0
> thp_collapse_alloc 0
> thp_collapse_alloc_failed 0
> thp_file_alloc 0
> thp_file_mapped 0
> thp_split_page 0
> thp_split_page_failed 0
> thp_deferred_split_page 0
> thp_split_pmd 0
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
>
> kern.log OOM message:
> [737778.724194] snmpd invoked oom-killer:
> gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
> [737778.724246] snmpd cpuset=/ mems_allowed=0-1
> [737778.724278] CPU: 15 PID: 2976 Comm: snmpd Tainted: G W I 4.8.4 #1
> [737778.724352] 0000000000000000 ffffffff81292069 ffff88041e043c48
> ffff88041e043c48
> [737778.724403] ffffffff8118d1f6 ffff88041dd70fc0 ffff88041e043c48
> 000000000136236f
> [737778.724454] ffffffff8170e11e 0000000000000001 ffffffff8112a700
> 000000000000030f
> [737778.724505] Call Trace:
> [737778.724533] [<ffffffff81292069>] ? dump_stack+0x46/0x5d
> [737778.727077] [<ffffffff8118d1f6>] ? dump_header.isra.16+0x56/0x185
> [737778.727108] [<ffffffff8112a700>] ? oom_kill_process+0x210/0x3c0
> [737778.727136] [<ffffffff8112ac4b>] ? out_of_memory+0x34b/0x420
> [737778.727165] [<ffffffff8112fcca>] ? __alloc_pages_nodemask+0xd9a/0xde0
> [737778.727195] [<ffffffff811768e1>] ? alloc_pages_vma+0xc1/0x240
> [737778.727223] [<ffffffff81126512>] ? pagecache_get_page+0x22/0x230
> [737778.727253] [<ffffffff81169f44>] ? __read_swap_cache_async+0x104/0x180
> [737778.727282] [<ffffffff81169fcf>] ? read_swap_cache_async+0xf/0x30
> [737778.727311] [<ffffffff8116a0dc>] ? swapin_readahead+0xec/0x1a0
> [737778.727340] [<ffffffff81156270>] ? do_swap_page+0x420/0x5c0
> [737778.727369] [<ffffffff813f36d8>] ? SYSC_recvfrom+0xa8/0x110
> [737778.727397] [<ffffffff81157a39>] ? handle_mm_fault+0x629/0xe30
> [737778.727426] [<ffffffff81048fc5>] ? __do_page_fault+0x1b5/0x480
> [737778.727456] [<ffffffff814fbaa2>] ? page_fault+0x22/0x30
> [737778.727497] Mem-Info:
> [737778.727524] active_anon:24 inactive_anon:49 isolated_anon:0
> [737778.727524] active_file:6920154 inactive_file:798043 isolated_file:576
> [737778.727524] unevictable:0 dirty:800528 writeback:1307 unstable:0
> [737778.727524] slab_reclaimable:264367 slab_unreclaimable:193348
> [737778.727524] mapped:4063 shmem:0 pagetables:1719 bounce:0
> [737778.727524] free:39225 free_pcp:47 free_cma:0
> [737778.727677] Node 0 active_anon:16kB inactive_anon:76kB
> active_file:14249324kB inactive_file:1296908kB unevictable:0kB
> isolated(anon):0kB isolated(file):1920kB mapped:10432kB
> dirty:1308528kB writeback:0kB shmem:0kB shmem_thp: 0kB
> shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
> pages_scanned:23557303 all_unreclaimable? yes
> [737778.727806] Node 1 active_anon:80kB inactive_anon:120kB
> active_file:13431292kB inactive_file:1895264kB unevictable:0kB
> isolated(anon):0kB isolated(file):384kB mapped:5820kB dirty:1893584kB
> writeback:5228kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB
> anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:25598673
> all_unreclaimable? yes
> [737778.727930] Node 0 Normal free:44864kB min:45192kB low:61736kB
> high:78280kB active_anon:16kB inactive_anon:76kB
> active_file:14249324kB inactive_file:1296908kB unevictable:0kB
> writepending:1308528kB present:16777216kB managed:16544856kB
> mlocked:0kB slab_reclaimable:562644kB slab_unreclaimable:317504kB
> kernel_stack:3840kB pagetables:3672kB bounce:0kB free_pcp:20kB
> local_pcp:0kB free_cma:0kB
> [737778.728066] lowmem_reserve[]: 0 0 0 0
> [737778.728100] Node 1 DMA free:15896kB min:40kB low:52kB high:64kB
> active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
> unevictable:0kB writepending:0kB present:15996kB managed:15896kB
> mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
> kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
> free_cma:0kB
> [737778.728228] lowmem_reserve[]: 0 3216 16044 16044
> [737778.728263] Node 1 DMA32 free:60300kB min:8996kB low:12288kB
> high:15580kB active_anon:4kB inactive_anon:4kB active_file:2660988kB
> inactive_file:474956kB unevictable:0kB writepending:475116kB
> present:3378660kB managed:3304720kB mlocked:0kB
> slab_reclaimable:83612kB slab_unreclaimable:16668kB kernel_stack:320kB
> pagetables:16kB bounce:0kB free_pcp:4kB local_pcp:4kB free_cma:0kB
> [737778.728397] lowmem_reserve[]: 0 0 12827 12827
> [737778.728431] Node 1 Normal free:35840kB min:35876kB low:49008kB
> high:62140kB active_anon:76kB inactive_anon:116kB
> active_file:10770304kB inactive_file:1420308kB unevictable:0kB
> writepending:1423696kB present:13369344kB managed:13135424kB
> mlocked:0kB slab_reclaimable:411212kB slab_unreclaimable:439220kB
> kernel_stack:2864kB pagetables:3188kB bounce:0kB free_pcp:164kB
> local_pcp:36kB free_cma:0kB
> [737778.728568] lowmem_reserve[]: 0 0 0 0
> [737778.728601] Node 0 Normal: 11208*4kB (UME) 4*8kB (U) 0*16kB 0*32kB
> 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44864kB
> [737778.728686] Node 1 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB
> (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB
> (M) = 15896kB
> [737778.728786] Node 1 DMA32: 11759*4kB (UME) 1658*8kB (UM) 0*16kB
> 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
> 60300kB
> [737778.728875] Node 1 Normal: 7984*4kB (UME) 470*8kB (UME) 3*16kB (U)
> 3*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
> = 35840kB
> [737778.728973] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [737778.729019] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [737778.729065] Node 1 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [737778.729111] Node 1 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [737778.729156] 7718841 total pagecache pages
> [737778.729179] 68 pages in swap cache
> [737778.729202] Swap cache stats: add 193888, delete 193820, find 160188/213014
> [737778.729231] Free swap = 48045076kB
> [737778.729254] Total swap = 48300028kB
> [737778.729277] 8385304 pages RAM
> [737778.729299] 0 pages HighMem/MovableOnly
> [737778.729322] 135080 pages reserved
> [737778.729344] 0 pages hwpoisoned
> [737778.729365] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds
> swapents oom_score_adj name
> [737778.729417] [ 1927] 0 1927 9941 447 22 3
> 299 -1000 systemd-udevd
> [737778.729465] [ 2812] 0 2812 9289 412 23 4
> 161 0 rpcbind
> [737778.729512] [ 2836] 102 2836 9320 414 23 3
> 151 0 rpc.statd
> [737778.729560] [ 2851] 104 2851 162257 276 75 3
> 7489 0 apt-cacher-ng
> [737778.729608] [ 2856] 0 2856 13796 345 31 3
> 167 -1000 sshd
> [737778.729655] [ 2857] 0 2857 64668 504 27 4
> 355 0 rsyslogd
> [737778.729702] [ 2858] 0 2858 6876 518 18 3
> 83 0 cron
> [737778.729748] [ 2859] 0 2859 4756 360 14 3
> 44 0 atd
> [737778.729795] [ 2860] 0 2860 7059 523 18 3
> 591 0 smartd
> [737778.729842] [ 2864] 0 2864 7082 559 19 4
> 96 0 systemd-logind
> [737778.729890] [ 2865] 106 2865 10563 528 24 3
> 110 -900 dbus-daemon
> [737778.729938] [ 2925] 0 2925 3604 421 12 3
> 38 0 agetty
> [737778.729985] [ 2974] 0 2974 4852 365 13 3
> 73 0 irqbalance
> [737778.730032] [ 2976] 105 2976 14299 496 29 3
> 1534 0 snmpd
> [737778.730078] [ 2992] 0 2992 3180 227 11 3
> 38 0 mcelog
> [737778.730125] [ 3095] 0 3095 26571 344 43 3
> 259 0 sfcbd
> [737778.730172] [ 3172] 0 3172 20392 261 40 3
> 236 0 sfcbd
> [737778.730219] [ 3248] 0 3248 22441 0 41 3
> 238 0 sfcbd
> [737778.730265] [ 3249] 0 3249 39376 155 44 3
> 357 0 sfcbd
> [737778.730312] [ 3450] 0 3450 39377 104 44 3
> 244 0 sfcbd
> [737778.730359] [ 3467] 0 3467 58324 301 46 3
> 284 0 sfcbd
> [737778.730405] [ 3548] 0 3548 262686 643 66 4
> 4097 0 dsm_sa_datamgrd
> [737778.730453] [ 3563] 101 3563 13312 403 29 3
> 162 0 exim4
> [737778.730499] [ 3576] 107 3576 7293 493 19 3
> 148 0 ntpd
> [737778.730546] [ 3585] 0 3585 61531 577 117 3
> 496 0 winbindd
> [737778.730593] [ 3586] 0 3586 61531 578 118 3
> 512 0 winbindd
> [737778.730640] [ 3651] 0 3651 48584 566 36 3
> 487 0 dsm_sa_eventmgr
> [737778.730688] [ 3674] 0 3674 99593 576 47 3
> 1402 0 dsm_sa_snmpd
> [737778.730736] [ 3717] 0 3717 7923 285 18 3
> 115 0 dsm_om_connsvcd
> [737778.730784] [ 3718] 0 3718 740234 1744 202 7
> 30685 0 dsm_om_connsvcd
> [737778.730832] [ 3736] 0 3736 178651 0 55 3
> 3789 0 dsm_sa_datamgrd
> [737778.730880] [ 4056] 0 4056 26472 498 57 3
> 252 0 sshd
> [737778.730926] [ 4060] 1000 4060 8973 501 23 3
> 184 0 systemd
> [737778.730973] [ 4061] 1000 4061 15702 0 34 4
> 612 0 (sd-pam)
> [737778.731020] [ 4063] 1000 4063 26472 158 54 3
> 260 0 sshd
> [737778.731067] [ 4064] 1000 4064 6041 739 16 3
> 686 0 bash
> [737778.731113] [ 4083] 1000 4083 16853 493 37 3
> 128 0 su
> [737778.731160] [ 4084] 0 4084 5501 756 15 3
> 160 0 bash
> [737778.731207] [15150] 0 15150 3309 678 10 3
> 57 0 run_mirror.sh
> [737778.731256] [24296] 0 24296 1450 139 8 3
> 23 0 flock
> [737778.731302] [24297] 0 24297 9576 622 22 3
> 3990 0 rsync
> [737778.731349] [24298] 0 24298 7552 541 18 3
> 1073 0 rsync
> [737778.731395] [24299] 0 24299 9522 401 22 3
> 2416 0 rsync
> [737778.731445] [25910] 0 25910 10257 522 23 3
> 81 0 systemd-journal
> [737778.731494] [25940] 0 25940 16365 617 37 3
> 126 0 cron
> [737778.731540] Out of memory: Kill process 3718 (dsm_om_connsvcd)
> score 1 or sacrifice child
> [737778.731644] Killed process 3718 (dsm_om_connsvcd)
> total-vm:2960936kB, anon-rss:0kB, file-rss:6976kB, shmem-rss:0kB
> [737778.768375] oom_reaper: reaped process 3718 (dsm_om_connsvcd), now
> anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
>
> On Fri, Nov 4, 2016 at 5:00 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
>> On 11/04/2016 03:13 PM, E V wrote:
>>> After the system panic'd yesterday I booted back into 4.8.4 and
>>> restarted the rsync's. I'm away on vacation next week, so when I get
>>> back I'll get rc4 or rc5 and try again. In the mean time here's data
>>> from the system running 4.8.4 without problems for about a day. I'm
>>> not familiar with xxd and didn't see a -e option, so used -E:
>>> xxd -E -g8 -c8 /proc/kpagecount | cut -d" " -f2 | sort | uniq -c
>>> 8258633 0000000000000000
>>> 216440 0100000000000000
>>
>> The lack of -e means it's big endian, which is not a big issue. So here
>> most of memory is free, some pages have just one pin, and only
>> relatively few have more. The vmstats also doesn't show anything bad, so
>> we'll have to wait if something appears within the week, or after you
>> try 4.9 again. Thanks.
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 17:04 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <fd1c804d-3e44-0321-8a3e-67d6ff7357fa@cumulusnetworks.com>
On 14.11.2016 17:55, David Ahern wrote:
> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>> saddr, the returned dst actually corresponds to a net device that has
>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>> v4; this makes it easy to use the same error handlers for both cases.
>>>
>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>> ---
>>> Changes from v2:
>>> It turns out ipv6_chk_addr already has the device enumeration
>>> logic that we need by simply passing NULL.
>>>
>>> net/ipv6/ip6_output.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>> index 6001e78..b3b5cb6 100644
>>> --- a/net/ipv6/ip6_output.c
>>> +++ b/net/ipv6/ip6_output.c
>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>> const struct sock *sk,
>>> int err;
>>> int flags = 0;
>>>
>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>> + return -EINVAL;
>>
>> Hmm, this check is too permissive, no?
>>
>> E.g. what happens if you move a link local address from one interface to
>> another? In this case this code would still allow the saddr to be used.
>
> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
But in this case we should actually bail out, no?
Let's say, user assumes we are on ifindex eth0 with LL address from
eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
accept this source address anymore and need to return -EINVAL, too.
>> I just also quickly read up on the history (sorry was travelling last
>> week) and wonder if you ever saw a user space facing bug or if this is
>> basically some difference you saw while writing out of tree code?
>
> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
Hmm, so it fixes no real bug.
Because of translations of flowi6_oif we actually can't do a correct
check of source address for cases like the one I outlined above? Hmm,
maybe we should simply depend on user space checks.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver
From: Rob Herring @ 2016-11-14 17:04 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <1478540043-24558-2-git-send-email-stanimir.varbanov@linaro.org>
On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> .../devicetree/bindings/media/qcom,venus.txt | 98 ++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
> new file mode 100644
> index 000000000000..b2af347fbce4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -0,0 +1,98 @@
> +* Qualcomm Venus video encode/decode accelerator
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Value should contain one of:
> + - "qcom,venus-msm8916"
> + - "qcom,venus-msm8996"
The normal ordering is <vendor>,<soc>-<block>
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "venus" Venus register base
> +- reg-names:
I'd prefer these grouped as one entry for reg-names.
> + Usage: optional for msm8996
Why optional?
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "vmem" Video memory register base
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain interrupts as listed in the interrupt-names
> + property.
> +- interrupt-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "venus" Venus interrupt line
> +- interrupt-names:
> + Usage: optional for msm8996
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "vmem" Video memory interrupt line
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A List of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "core" Core video accelerator clock
> + - "iface" Video accelerator AHB clock
> + - "bus" Video accelerator AXI clock
> +- clock-names:
> + Usage: required for msm8996
Plus the 3 above?
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "subcore0" Subcore0 video accelerator clock
> + - "subcore1" Subcore1 video accelerator clock
> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
> + - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
> + - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
> + - "mmagic_video_bus" MMAGIC video AXI clock
> + - "video_mbus" Video MAXI clock
> +- clock-names:
> + Usage: optional for msm8996
Clocks shouldn't be optional unless you failed to add in an initial
binding.
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "vmem_bus" Video memory MAXI clock
> + - "vmem_iface" Video memory AHB clock
> +- power-domains:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- rproc:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle to remote processor responsible for
> + firmware loading and processor booting.
> +
> +- iommus:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* An Example
> + video-codec@1d00000 {
> + compatible = "qcom,venus-msm8916";
> + reg = <0x01d00000 0xff000>;
> + reg-names = "venus";
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "venus";
> + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
> + <&gcc GCC_VENUS0_AHB_CLK>,
> + <&gcc GCC_VENUS0_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + power-domains = <&gcc VENUS_GDSC>;
> + rproc = <&venus_rproc>;
> + iommus = <&apps_iommu 5>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support
From: Tom Rini @ 2016-11-14 17:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <72ae8842-6bce-5757-5e2c-be9d418e7a9a@redhat.com>
On Mon, Nov 14, 2016 at 03:21:41PM +0100, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 15:12, Maxime Ripard wrote:
> >On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> >>> #ifdef CONFIG_SPL_SPI_SUNXI
> >>>@@ -143,7 +157,14 @@
> >>> #define CONFIG_GENERIC_MMC
> >>> #define CONFIG_MMC_SUNXI
> >>> #define CONFIG_MMC_SUNXI_SLOT 0
> >>>-#define CONFIG_ENV_IS_IN_MMC
> >>>+#endif
> >>>+
> >>>+#if defined(CONFIG_ENV_IS_IN_NAND)
> >>>+#define CONFIG_ENV_OFFSET 0xc00000
> >>>+#define CONFIG_ENV_SIZE 0x400000
> >>>+#elif defined(CONFIG_ENV_IS_IN_MMC)
> >>>+#define CONFIG_ENV_OFFSET (544 << 10) /* (8 + 24 + 512) KiB */
> >>>+#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */
> >>> #define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC controller */
> >>> #endif
> >
> >Oh, and this part is broken. It relies on the fact that all board
> >define ENV_IS_IN_MMC (which they should), while obviously they
> >don't. I'm not exactly sure about what the proper fix would be.
>
> Yes, this has been a known problem for a while, but never
> became an issue due to lack of NAND support.
>
> My preferred way for dealing with this be would for the
> environment code in u-boot allowing to build in multiple
> back-ends and use spl_boot_device() which then would need
> to loose its spl prefix. For the CHIP devices I'm sure
> you can come up with a simpler fix since those don't
> have an sdcard-slot. But for other boards this will be
> necessary as we really don't want to have separate
> nand and mmc u-boot.bin files.
>
> Anyways this is something for whomever will take over
> as sunxi custodian from me. Maybe someone from free-electrons
> can co-maintain with Jagan ?
I would really like to see the co-maintainer model continue here, if
possible, yes. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/26d75453/attachment.sig>
^ permalink raw reply
* Re: Change call ABI on PA-RISC
From: Jeff Law @ 2016-11-14 17:02 UTC (permalink / raw)
To: Helge Deller, John David Anglin; +Cc: linux-parisc@vger.kernel.org
In-Reply-To: <491e8502-17a3-f203-0c9a-273a988ee0ee@gmx.de>
On 11/14/2016 09:24 AM, Helge Deller wrote:
> On 14.11.2016 16:11, John David Anglin wrote:
>> On 2016-11-14 3:21 AM, Jeff Law wrote:
>>> On 11/13/2016 12:48 PM, Helge Deller wrote:
>>>> On 13.11.2016 19:56, Jeff Law wrote:
>>>>> On 11/13/2016 11:37 AM, Helge Deller wrote:
>>>>>> If you are going to change the ABI, maybe we can add more
>>>>>> things as well? Which comes to my mind here is for example an
>>>>>> optimized mcount() function which allows changing the return
>>>>>> pointer (see -mmcount-ra-address on MIPS) ?
>>>>
>>>>> As in twiddling RP to return to a different point?
>>>>
>>>> No, that's not the use case for me.
>
> I was wrong.
> It's actually the use case to modify the RP...
>
>>>> I was working on the ftrace functionality in the Linux kernel.
>>>> I'd need to look up the full details again, but as far as I
>>>> remember one of the tracers wants to know the function to which
>>>> the caller of mcount() would return, so some kind of simple
>>>> __builtin_return_address(2).
>
>>> Ah. Isn't that going to be sitting at sp-20 or something like
>>> that. My PA is rusty, but my recollection is that's supposed to be
>>> at a fixed location in the frame.
>
> Yes, sp-10.
>
> 0000000000000000 <irq_to_desc>:
> 0: 08 03 02 41 copy r3,r1
> 4: 0f c2 12 c1 std rp,-10(sp)
> 8: 08 1e 02 43 copy sp,r3
> c: 73 c1 00 a8 std,ma r1,50(sp)
> 10: 37 dd 00 20 ldo 10(sp),ret1
> 14: 0c 65 12 d0 std r5,8(r3)
> 18: 00 00 14 b9 mfia r25
> 1c: db 45 0b e0 extrd,u,* r26,63,32,r5
> 20: 70 64 00 20 std r4,10(r3)
> 24: 08 02 02 5a copy rp,r26
> 28: 37 39 3f d1 ldo -18(r25),r25
> 2c: 08 1b 02 44 copy dp,r4
> 30: 2b 60 00 00 addil L%0,dp,r1
> 34: 50 21 00 00 ldd 0(r1),r1
> 38: 0c 20 10 c1 ldd 0(r1),r1
> 3c: 50 22 00 20 ldd 10(r1),rp
> 40: e8 40 f0 00 bve,l (rp),rp
> 44: 50 3b 00 30 ldd 18(r1),dp
>
>
>> The return address of the the function to which the caller of
>> mcount() would return is passed to mcount() in %r26. The saved value
>> in the frame is not directly useful as one lacks the frame offset of
>> the routine calling mcount.
>
> What I want to archieve is to modify the return pointer, in order
> to be able to track when the function returns to his caller.
> The kernel ftracer uses this then to generate call stacks and to
> time the function.
> Looking at the above code, it should then be possible for me
> to modify -10(r3), but is there a guarantee that it's always at
> -10(r3) and that r3 is used?
I don't think you can depend on r3 (frame pointer). But IIRC the save
slot for the return address is fixed. I think the problem you're going
to run into is that the RP is saved into the frame allocated by the
caller, then we adjust the SP for the current function. So without
knowing the size of the current function's frame, you're hosed.
Jeff
^ permalink raw reply
* Re: Change call ABI on PA-RISC
From: John David Anglin @ 2016-11-14 17:02 UTC (permalink / raw)
To: Helge Deller, Jeff Law; +Cc: linux-parisc@vger.kernel.org
In-Reply-To: <491e8502-17a3-f203-0c9a-273a988ee0ee@gmx.de>
On 2016-11-14 11:24 AM, Helge Deller wrote:
> On 14.11.2016 16:11, John David Anglin wrote:
>> On 2016-11-14 3:21 AM, Jeff Law wrote:
>>> On 11/13/2016 12:48 PM, Helge Deller wrote:
>>>> On 13.11.2016 19:56, Jeff Law wrote:
>>>>> On 11/13/2016 11:37 AM, Helge Deller wrote:
>>>>>> If you are going to change the ABI, maybe we can add more
>>>>>> things as well? Which comes to my mind here is for example an
>>>>>> optimized mcount() function which allows changing the return
>>>>>> pointer (see -mmcount-ra-address on MIPS) ?
>>>>> As in twiddling RP to return to a different point?
>>>> No, that's not the use case for me.
> I was wrong.
> It's actually the use case to modify the RP...
>
>>>> I was working on the ftrace functionality in the Linux kernel.
>>>> I'd need to look up the full details again, but as far as I
>>>> remember one of the tracers wants to know the function to which
>>>> the caller of mcount() would return, so some kind of simple
>>>> __builtin_return_address(2).
>>> Ah. Isn't that going to be sitting at sp-20 or something like
>>> that. My PA is rusty, but my recollection is that's supposed to be
>>> at a fixed location in the frame.
> Yes, sp-10.
It's sp-0x10 on 64-bit and sp-0x14 on 32-bit.
>
> 0000000000000000 <irq_to_desc>:
> 0: 08 03 02 41 copy r3,r1
> 4: 0f c2 12 c1 std rp,-10(sp)
> 8: 08 1e 02 43 copy sp,r3
> c: 73 c1 00 a8 std,ma r1,50(sp)
> 10: 37 dd 00 20 ldo 10(sp),ret1
> 14: 0c 65 12 d0 std r5,8(r3)
> 18: 00 00 14 b9 mfia r25
> 1c: db 45 0b e0 extrd,u,* r26,63,32,r5
> 20: 70 64 00 20 std r4,10(r3)
> 24: 08 02 02 5a copy rp,r26
> 28: 37 39 3f d1 ldo -18(r25),r25
> 2c: 08 1b 02 44 copy dp,r4
> 30: 2b 60 00 00 addil L%0,dp,r1
> 34: 50 21 00 00 ldd 0(r1),r1
> 38: 0c 20 10 c1 ldd 0(r1),r1
> 3c: 50 22 00 20 ldd 10(r1),rp
> 40: e8 40 f0 00 bve,l (rp),rp
> 44: 50 3b 00 30 ldd 18(r1),dp
>
>
>> The return address of the the function to which the caller of
>> mcount() would return is passed to mcount() in %r26. The saved value
>> in the frame is not directly useful as one lacks the frame offset of
>> the routine calling mcount.
> What I want to archieve is to modify the return pointer, in order
> to be able to track when the function returns to his caller.
> The kernel ftracer uses this then to generate call stacks and to
> time the function.
> Looking at the above code, it should then be possible for me
> to modify -10(r3), but is there a guarantee that it's always at
> -10(r3) and that r3 is used?
The location for the for saving the return pointer is defined and always
the same.
If routine is compiled with "-fno-omit-frame-pointer", there will always
be a
frame pointer and it should be %r3. Otherwise, there's no guarantee
that the
frame pointer won't be eliminated.
Since the routine calls mcount, I believe the return pointer will be
always be saved
and restored from the frame marker. So, it should be possible the
return address
on the stack to detect when the routine completes..
> That's the reason I asked if we could modify mcount to
> give the address (in the stack) of the return pointer, but maybe
> it's just overkill for this use case ?
If "-fno-omit-frame-pointer" works, then you have what you need.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply
* Re: [Qemu-devel] [PULL v2 0/9] Ide patches
From: John Snow @ 2016-11-14 17:01 UTC (permalink / raw)
To: qemu-devel; +Cc: famz, peter.maydell
In-Reply-To: <147914275667.238.7399833850728779563@9040ca97f87d>
On 11/14/2016 11:59 AM, no-reply@patchew.org wrote:
> Hi,
>
> Your series seems to have some coding style problems. See output below for
> more information:
>
All failures below are intentional deviations.
> Type: series
> Subject: [Qemu-devel] [PULL v2 0/9] Ide patches
> Message-id: 1479140746-22142-1-git-send-email-jsnow@redhat.com
>
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
>
> BASE=base
> n=1
> total=$(git log --oneline $BASE.. | wc -l)
> failed=0
>
> # Useful git options
> git config --local diff.renamelimit 0
> git config --local diff.renames True
>
> commits="$(git log --format=%H --reverse $BASE..)"
> for c in $commits; do
> echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
> if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
> failed=1
> echo
> fi
> n=$((n+1))
> done
>
> exit $failed
> === TEST SCRIPT END ===
>
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
> * [new tag] patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com -> patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com
> Switched to a new branch 'test'
> aac853f ahci-test: add QMP tray test for ATAPI
> 9aff593 libqos/ahci: Add get_sense and test_ready
> 7163df5 libqos/ahci: Add ATAPI tray macros
> f1e2266 libqos/ahci: Support expected errors
> 3968b94 libqtest: add qmp_eventwait_ref
> 9d13ef0 block-backend: Always notify on blk_eject
> 341ba04 ahci-test: test atapi read_cd with bcl, nb_sectors = 0
> 8990ba8 ahci-test: Create smaller test ISO images
> e3e34c1 atapi: classify read_cd as conditionally returning data
>
> === OUTPUT BEGIN ===
> fatal: unrecognized argument: --no-patch
> Checking PATCH 1/9: ...
> ERROR: space prohibited after that open square bracket '['
> #92: FILE: hw/ide/atapi.c:1324:
> + [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
>
> ERROR: space prohibited before that close square bracket ']'
> #92: FILE: hw/ide/atapi.c:1324:
> + [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
>
> total: 2 errors, 0 warnings, 86 lines checked
>
This is intentional and won't change, at least not for this patch. If we
truly want to restructure the command table, I can -- but another time.
--js
> Your patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> fatal: unrecognized argument: --no-patch
> Checking PATCH 2/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 3/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 4/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 5/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 6/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 7/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 8/9: ...
> fatal: unrecognized argument: --no-patch
> Checking PATCH 9/9: ...
> === OUTPUT END ===
>
> Test command exited with code: 1
>
>
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-devel@freelists.org
>
^ permalink raw reply
* [PATCH v2 1/2] mtd: nand: Support controllers with custom page
From: Marc Gonzalez @ 2016-11-14 17:01 UTC (permalink / raw)
To: Boris Brezillon, Richard Weinberger; +Cc: linux-mtd, Mason, Sebastian Frias
In-Reply-To: <20161114111122.27804c4e@bbrezillon>
If your controller already sends the required NAND commands when
reading or writing a page, then the framework is not supposed to
send READ0 and SEQIN/PAGEPROG respectively.
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
---
v2:
(chip) in NAND_HAS_SUBPAGE_WRITE macro
s/nand_default_page_accessors/nand_standard_page_accessors/
scripts/checkpatch.pl --strict v2-0001-mtd-nand-Support-controllers-with-custom-page-acc.patch
total: 0 errors, 0 warnings, 0 checks, 91 lines checked
---
drivers/mtd/nand/nand_base.c | 31 ++++++++++++++++++++++++++++---
include/linux/mtd/nand.h | 12 ++++++++++++
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 50cdf37cb8e4..db5f27db3748 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1970,7 +1970,8 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
__func__, buf);
read_retry:
- chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, page);
+ if (nand_standard_page_accessors(&chip->ecc))
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, page);
/*
* Now read the page into the buffer. Absent an error,
@@ -2658,7 +2659,8 @@ static int nand_write_page(struct mtd_info *mtd, struct nand_chip *chip,
else
subpage = 0;
- chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
+ if (nand_standard_page_accessors(&chip->ecc))
+ chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
if (unlikely(raw))
status = chip->ecc.write_page_raw(mtd, chip, buf,
@@ -2681,7 +2683,8 @@ static int nand_write_page(struct mtd_info *mtd, struct nand_chip *chip,
if (!cached || !NAND_HAS_CACHEPROG(chip)) {
- chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+ if (nand_standard_page_accessors(&chip->ecc))
+ chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
status = chip->waitfunc(mtd, chip);
/*
* See if operation failed and additional status checks are
@@ -4539,6 +4542,25 @@ static bool nand_ecc_strength_good(struct mtd_info *mtd)
return corr >= ds_corr && ecc->strength >= chip->ecc_strength_ds;
}
+static bool invalid_ecc_page_accessors(struct nand_chip *chip)
+{
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+ if (nand_standard_page_accessors(ecc))
+ return false;
+
+ /*
+ * NAND_ECC_CUSTOM_PAGE_ACCESS flag is set, make sure the NAND
+ * controller driver implements all the page accessors because
+ * default helpers are not suitable when the core does not
+ * send the READ0/PAGEPROG commands.
+ */
+ return (!ecc->read_page || !ecc->write_page ||
+ !ecc->read_page_raw || !ecc->write_page_raw ||
+ (NAND_HAS_SUBPAGE_READ(chip) && !ecc->read_subpage) ||
+ (NAND_HAS_SUBPAGE_WRITE(chip) && !ecc->write_subpage));
+}
+
/**
* nand_scan_tail - [NAND Interface] Scan for the NAND device
* @mtd: MTD device structure
@@ -4559,6 +4581,9 @@ int nand_scan_tail(struct mtd_info *mtd)
!(chip->bbt_options & NAND_BBT_USE_FLASH)))
return -EINVAL;
+ if (WARN_ON(invalid_ecc_page_accessors(chip)))
+ return -EINVAL;
+
if (!(chip->options & NAND_OWN_BUFFERS)) {
nbuf = kzalloc(sizeof(*nbuf) + mtd->writesize
+ mtd->oobsize * 3, GFP_KERNEL);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 06d0c9d740f7..c5f3a012ae62 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -142,6 +142,12 @@ enum nand_ecc_algo {
*/
#define NAND_ECC_GENERIC_ERASED_CHECK BIT(0)
#define NAND_ECC_MAXIMIZE BIT(1)
+/*
+ * If your controller already sends the required NAND commands when
+ * reading or writing a page, then the framework is not supposed to
+ * send READ0 and SEQIN/PAGEPROG respectively.
+ */
+#define NAND_ECC_CUSTOM_PAGE_ACCESS BIT(2)
/* Bit mask for flags passed to do_nand_read_ecc */
#define NAND_GET_DEVICE 0x80
@@ -186,6 +192,7 @@ enum nand_ecc_algo {
/* Macros to identify the above */
#define NAND_HAS_CACHEPROG(chip) ((chip->options & NAND_CACHEPRG))
#define NAND_HAS_SUBPAGE_READ(chip) ((chip->options & NAND_SUBPAGE_READ))
+#define NAND_HAS_SUBPAGE_WRITE(chip) !((chip)->options & NAND_NO_SUBPAGE_WRITE)
/* Non chip related options */
/* This option skips the bbt scan during initialization. */
@@ -568,6 +575,11 @@ struct nand_ecc_ctrl {
int page);
};
+static inline int nand_standard_page_accessors(struct nand_ecc_ctrl *ecc)
+{
+ return !(ecc->options & NAND_ECC_CUSTOM_PAGE_ACCESS);
+}
+
/**
* struct nand_buffers - buffer structure for read/write
* @ecccalc: buffer pointer for calculated ECC, size is oobsize.
--
2.9.0
^ permalink raw reply related
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 17:04 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <fd1c804d-3e44-0321-8a3e-67d6ff7357fa@cumulusnetworks.com>
On 14.11.2016 17:55, David Ahern wrote:
> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>> saddr, the returned dst actually corresponds to a net device that has
>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>> v4; this makes it easy to use the same error handlers for both cases.
>>>
>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>> ---
>>> Changes from v2:
>>> It turns out ipv6_chk_addr already has the device enumeration
>>> logic that we need by simply passing NULL.
>>>
>>> net/ipv6/ip6_output.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>> index 6001e78..b3b5cb6 100644
>>> --- a/net/ipv6/ip6_output.c
>>> +++ b/net/ipv6/ip6_output.c
>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>> const struct sock *sk,
>>> int err;
>>> int flags = 0;
>>>
>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>> + return -EINVAL;
>>
>> Hmm, this check is too permissive, no?
>>
>> E.g. what happens if you move a link local address from one interface to
>> another? In this case this code would still allow the saddr to be used.
>
> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
But in this case we should actually bail out, no?
Let's say, user assumes we are on ifindex eth0 with LL address from
eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
accept this source address anymore and need to return -EINVAL, too.
>> I just also quickly read up on the history (sorry was travelling last
>> week) and wonder if you ever saw a user space facing bug or if this is
>> basically some difference you saw while writing out of tree code?
>
> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
Hmm, so it fixes no real bug.
Because of translations of flowi6_oif we actually can't do a correct
check of source address for cases like the one I outlined above? Hmm,
maybe we should simply depend on user space checks.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables
From: Jeff King @ 2016-11-14 17:01 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Lars Schneider, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, git
In-Reply-To: <35d3a07d-5d2f-aedd-94bc-4d92e5aa4661@web.de>
On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
> > What is the goal for 'pu'?
>
> > (1) Builds clean on all platforms + passes all tests
> Yes
> > (2) Builds clean on all platforms
> Yes
> > (3) Builds clean on Linux
> Yes
> > (4) Just makes new topics easily available to a broader audience
> Yes
I'd have answered differently, though I think in the end we agree on the
outcome.
I think the only thing that matters is (4). It _usually_ builds and
passes all tests, but not always. But the point is that nobody should
care in particular about "pu". What we care about is whether the
individual topics will build and pass before they are merged to master
(or even "next").
So "pu" is a tool, because you can test all of the topics at once and
find out early if there are any problems. And it's good to investigate
problems there before topics hit next (though they are also often caught
in review, or by people trying the broken topic on their various
platforms, or sometimes Junio even pushes out a known-broken state in pu
and mentions it in "What's cooking").
So yes, it should do all of those things, but we don't necessarily
expect that it will never be broken. That's expected to happen from time
to time, and the purpose of the branch. With respect to Lars' original
point:
> > Git 'pu' does not compile on macOS right now:
> > builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used uninitialized
> > whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
The next step is to make sure that the topic author is aware (in this
case, one assumes it's pb/bisect).
Better still is to make a patch that can either be applied on top, or
squashed as appropriate. I know that Ramsay Jones does this, for
example, with some of his sparse-related checks, and I'm pretty sure
from the turnaround-time that he runs it against "pu".
-Peff
^ permalink raw reply
* [U-Boot] [v2, 2/5] mmc: send STOP command when the READ/WRITE commands fail
From: york sun @ 2016-11-14 17:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <HE1PR04MB0889FC6C688873214283B489F8C80@HE1PR04MB0889.eurprd04.prod.outlook.com>
On 09/23/2016 12:38 AM, Y.B. Lu wrote:
>> ditto.
>
> [Lu Yangbo-B47093] Ok, I will check the return. Thanks :)
>>
Yangbo,
Do you have an update?
York
^ permalink raw reply
* Re: [PATCH 4/6] perf config: Add support for writing configs to a config file
From: Taeung Song @ 2016-11-14 17:00 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: linux-kernel, Jiri Olsa, Namhyung Kim, Ingo Molnar,
Peter Zijlstra, Wang Nan, Nambong Ha, Wookje Kwon
In-Reply-To: <20161114160442.GD26543@kernel.org>
Thank you for your review.
I have a question at the very bottom
(skip v2 I sent lately or not ?).
On 11/15/2016 01:04 AM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 04, 2016 at 03:44:20PM +0900, Taeung Song escreveu:
>> Add setting feature that can add config variables with their values
>> to a config file (i.e. user or system config file) or modify
>> config key-value pairs in a config file.
>> For the syntax examples,
>>
>> perf config [<file-option>] [section.name[=value] ...]
>>
>> e.g. You can set the ui.show-headers to false with
>>
>> # perf config ui.show-headers=false
>>
>> If you want to add or modify several config items, you can do like
>>
>> # perf config annotate.show_nr_jumps=false kmem.default=slab
>
> This works, but has some problems, see below:
>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Jiri Olsa <jolsa@kernel.org>
>> Cc: Wang Nan <wangnan0@huawei.com>
>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> ---
>> tools/perf/builtin-config.c | 66 ++++++++++++++++++++++++++++++++++++++++-----
>> tools/perf/util/config.c | 6 +++++
>> tools/perf/util/config.h | 2 ++
>> 3 files changed, 68 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
>> index fe253f3..5313702 100644
>> --- a/tools/perf/builtin-config.c
>> +++ b/tools/perf/builtin-config.c
>> @@ -17,7 +17,7 @@
>> static bool use_system_config, use_user_config;
>>
>> static const char * const config_usage[] = {
>> - "perf config [<file-option>] [options] [section.name ...]",
>> + "perf config [<file-option>] [options] [section.name[=value] ...]",
>> NULL
>> };
>>
>> @@ -33,6 +33,37 @@ static struct option config_options[] = {
>> OPT_END()
>> };
>>
>> +static int set_config(struct perf_config_set *set, const char *file_name,
>> + const char *var, const char *value)
>> +{
>> + struct perf_config_section *section = NULL;
>> + struct perf_config_item *item = NULL;
>> + const char *first_line = "# this file is auto-generated.";
>> + FILE *fp = fopen(file_name, "w");
>> +
>> + if (!fp)
>> + return -1;
>> + if (set == NULL)
>> + return -1;
>
> So, here fp is left open? I'm fixing this...
Understood. Sorry, I missed out it.
>> + perf_config_set__collect(set, var, value);
>> + fprintf(fp, "%s\n", first_line);
>> +
>> + /* overwrite configvariables */
> missing space?
Oops.. I missed a white space between two words.
>> + perf_config_items__for_each_entry(&set->sections, section) {
>> + fprintf(fp, "[%s]\n", section->name);
>> +
>> + perf_config_items__for_each_entry(§ion->items, item) {
>> + if (item->value)
>> + fprintf(fp, "\t%s = %s\n",
>> + item->name, item->value);
>> + }
>> + }
>> + fclose(fp);
>> +
>> + return 0;
>> +}
>> +
>> static int show_spec_config(struct perf_config_set *set, const char *var)
>> {
>> struct perf_config_section *section;
>> @@ -82,7 +113,7 @@ static int show_config(struct perf_config_set *set)
>> return 0;
>> }
>>
>> -static int parse_config_arg(char *arg, char **var)
>> +static int parse_config_arg(char *arg, char **var, char **value)
>> {
>> const char *last_dot = strchr(arg, '.');
>>
>> @@ -99,7 +130,21 @@ static int parse_config_arg(char *arg, char **var)
>> return -1;
>> }
>>
>> - *var = arg;
>> + *value = strchr(arg, '=');
>> + if (*value == NULL)
>> + *var = arg;
>> + else if (!strcmp(*value, "=")) {
>> + pr_err("The config variable does not contain a value: %s\n", arg);
>> + return -1;
>> + } else {
>> + *value = *value + 1; /* excluding a first character '=' */
>> + *var = strsep(&arg, "=");
>> + if (*var[0] == '\0') {
>> + pr_err("invalid config variable: %s\n", arg);
>> + return -1;
>> + }
>> + }
>> +
Here and..
>>
>> @@ -153,7 +198,8 @@ int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
>> default:
>> if (argc) {
>> for (i = 0; argv[i]; i++) {
>> - char *var, *arg = strdup(argv[i]);
>> + char *var, *value;
>> + char *arg = strdup(argv[i]);
>>
>> if (!arg) {
>> pr_err("%s: strdup failed\n", __func__);
>> @@ -161,13 +207,21 @@ int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
>> break;
>> }
>>
>> - if (parse_config_arg(arg, &var) < 0) {
>> + if (parse_config_arg(arg, &var, &value) < 0) {
>> free(arg);
>> ret = -1;
>> break;
>> }
>>
>> - ret = show_spec_config(set, var);
>> + if (value == NULL)
>> + ret = show_spec_config(set, var);
>> + else {
>> + const char *config_filename = config_exclusive_filename;
>> +
>> + if (!config_exclusive_filename)
>> + config_filename = user_config;
>> + ret = set_config(set, config_filename, var, value);
>> + }
>> free(arg);
Here, the parts are a bit different than v2 patchset I sent lately.
I refactored parse_config_arg() and a bit modify parsing
config arguments in cmd_config().
Is it better to just skip v2 patchset I sent ?
And remake new patchset regarding today your feedback ?
Or would I make v3 that adopts v2 I sent?
Thanks,
Taeung
>> }
>> } else
>> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>> index 18dae74..c8fb65d 100644
>> --- a/tools/perf/util/config.c
>> +++ b/tools/perf/util/config.c
>> @@ -602,6 +602,12 @@ static int collect_config(const char *var, const char *value,
>> return -1;
>> }
>>
>> +int perf_config_set__collect(struct perf_config_set *set,
>> + const char *var, const char *value)
>> +{
>> + return collect_config(var, value, set);
>> +}
>> +
>> static int perf_config_set__init(struct perf_config_set *set)
>> {
>> int ret = -1;
>> diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
>> index 6f813d4..0fcdb8c 100644
>> --- a/tools/perf/util/config.h
>> +++ b/tools/perf/util/config.h
>> @@ -33,6 +33,8 @@ const char *perf_etc_perfconfig(void);
>>
>> struct perf_config_set *perf_config_set__new(void);
>> void perf_config_set__delete(struct perf_config_set *set);
>> +int perf_config_set__collect(struct perf_config_set *set,
>> + const char *var, const char *value);
>> void perf_config__init(void);
>> void perf_config__exit(void);
>> void perf_config__refresh(void);
>> --
>> 2.7.4
^ permalink raw reply
* [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)
From: Yann E. MORIN @ 2016-11-14 17:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <41d484ce-4dfa-803e-c8d8-a216ee78f987@redhat.com>
Hans, Ian, All,
On 2016-11-14 12:53 +0100, Hans de Goede spake thusly:
> A while back I wrote:
>
> "Between my $dayjob, linux-sunxi, other foss projects and last but
> not least spending time with my wife and children I'm way too
> busy lately.
>
> So I've decided to seriously scale back my involvement in
> linux-sunxi, as such I'm going to step down as u-boot sunxi
> custodian."
So long, and thanks for all the fish! :-)
> So after this mail I'm going to send a mail updating
> the MAINTAINERS status of sunxi to orphan and I will also
> unsubscribe myself from the u-boot list to protect myself
> against getting dragged in again.
Don't forget to update (or get updated) the list of custodians on the
website (which is where I found the info):
http://www.denx.de/wiki/U-Boot/Custodians
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: [PATCH v4] staging: lustre: mdc: manage number of modify RPCs in flight
From: James Simmons @ 2016-11-14 16:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Andreas Dilger, Oleg Drokin, Gregoire Pichon,
Linux Kernel Mailing List, Lustre Development List
In-Reply-To: <20161114151737.GA18183@kroah.com>
> On Thu, Nov 10, 2016 at 10:51:13AM -0500, James Simmons wrote:
> > From: Gregoire Pichon <gregoire.pichon@bull.net>
> >
> > This patch is the main client part of a new feature that supports
> > multiple modify metadata RPCs in parallel. Its goal is to improve
> > metadata operations performance of a single client, while maintening
> > the consistency of MDT reply reconstruction and MDT recovery
> > mechanisms.
> >
> > It allows to manage the number of modify RPCs in flight within
> > the client obd structure and to assign a virtual index (the tag) to
> > each modify RPC to help server side cleaning of reply data.
> >
> > The mdc component uses this feature to send multiple modify RPCs
> > in parallel.
>
> Is this a new feature? Why should we take this now and not just wait
> until the code is out of staging?
Yes on the server side. So the problem on our meta data servers couldn't
handle writing mulitiple bits of data to the back end disk at ths same
time.
One client side the issue was the metadata operations were being
serialized by a mutex in the MDC layer. That is what this patch fixed.
So for the client it would be a performance improvement patch.
^ permalink raw reply
* [lustre-devel] [PATCH v4] staging: lustre: mdc: manage number of modify RPCs in flight
From: James Simmons @ 2016-11-14 16:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Andreas Dilger, Oleg Drokin, Gregoire Pichon,
Linux Kernel Mailing List, Lustre Development List
In-Reply-To: <20161114151737.GA18183@kroah.com>
> On Thu, Nov 10, 2016 at 10:51:13AM -0500, James Simmons wrote:
> > From: Gregoire Pichon <gregoire.pichon@bull.net>
> >
> > This patch is the main client part of a new feature that supports
> > multiple modify metadata RPCs in parallel. Its goal is to improve
> > metadata operations performance of a single client, while maintening
> > the consistency of MDT reply reconstruction and MDT recovery
> > mechanisms.
> >
> > It allows to manage the number of modify RPCs in flight within
> > the client obd structure and to assign a virtual index (the tag) to
> > each modify RPC to help server side cleaning of reply data.
> >
> > The mdc component uses this feature to send multiple modify RPCs
> > in parallel.
>
> Is this a new feature? Why should we take this now and not just wait
> until the code is out of staging?
Yes on the server side. So the problem on our meta data servers couldn't
handle writing mulitiple bits of data to the back end disk at ths same
time.
One client side the issue was the metadata operations were being
serialized by a mutex in the MDC layer. That is what this patch fixed.
So for the client it would be a performance improvement patch.
^ permalink raw reply
* Re: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
From: StDenis, Tom @ 2016-11-14 16:59 UTC (permalink / raw)
To: Deucher, Alexander, Zhu, Rex,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <MWHPR12MB16946EEC962184002298CE4DF7BC0-Gy0DoCVfaSW4WA4dJ5YXGAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4638 bytes --]
I just tried it on my Carrizo this morning (after sending out the dce6 patch) and everything seems peachy.
Tom
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Sent: Monday, November 14, 2016 11:56
To: Zhu, Rex; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Zhu, Rex
Subject: RE: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org] On Behalf
> Of Rex Zhu
> Sent: Friday, November 11, 2016 12:25 AM
> To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
>
> sw clockgate was used on uvd6.0.
> when uvd is idle, we gate the uvd clock.
> when decode, we ungate the uvd clock.
>
> Change-Id: I79ecdc5d0f48e97919386a08acca994f1fa05484
> Signed-off-by: Rex Zhu <Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
Assuming clockgating still works properly:
Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>
> ---
> drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 6 ++----
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c | 4 ++--
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> index 41fa351..ba2b66b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> @@ -2111,9 +2111,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
>
> if (gate) {
> if (pi->caps_uvd_pg) {
> - /* disable clockgating so we can properly shut down
> the block */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_UNGATE);
> +
> AMD_CG_STATE_GATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating failed
> to set clockgating state\n");
> return;
> @@ -2159,9 +2158,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
> return;
> }
>
> - /* enable clockgating. hw will dynamically
> gate/ungate clocks on the fly */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_GATE);
> +
> AMD_CG_STATE_UNGATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating Failed
> to set clockgating state\n");
> return;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> index 2028980..b0c63c5 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> @@ -169,7 +169,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> if (bgate) {
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_CG_STATE_UNGATE);
> + AMD_CG_STATE_GATE);
> cgs_set_powergating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> AMD_PG_STATE_GATE);
> @@ -182,7 +182,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> AMD_CG_STATE_UNGATE);
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_PG_STATE_GATE);
> + AMD_PG_STATE_UNGATE);
> cz_dpm_update_uvd_dpm(hwmgr, false);
> }
>
> --
> 1.9.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 10643 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PULL v2 0/9] Ide patches
From: no-reply @ 2016-11-14 16:59 UTC (permalink / raw)
To: jsnow; +Cc: famz, qemu-devel, peter.maydell
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v2 0/9] Ide patches
Message-id: 1479140746-22142-1-git-send-email-jsnow@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com -> patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com
Switched to a new branch 'test'
aac853f ahci-test: add QMP tray test for ATAPI
9aff593 libqos/ahci: Add get_sense and test_ready
7163df5 libqos/ahci: Add ATAPI tray macros
f1e2266 libqos/ahci: Support expected errors
3968b94 libqtest: add qmp_eventwait_ref
9d13ef0 block-backend: Always notify on blk_eject
341ba04 ahci-test: test atapi read_cd with bcl, nb_sectors = 0
8990ba8 ahci-test: Create smaller test ISO images
e3e34c1 atapi: classify read_cd as conditionally returning data
=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/9: ...
ERROR: space prohibited after that open square bracket '['
#92: FILE: hw/ide/atapi.c:1324:
+ [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
ERROR: space prohibited before that close square bracket ']'
#92: FILE: hw/ide/atapi.c:1324:
+ [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
total: 2 errors, 0 warnings, 86 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
fatal: unrecognized argument: --no-patch
Checking PATCH 2/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 6/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 7/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 8/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 9/9: ...
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.