* Re: [PATCH v2] md-cluster: fix safemode_delay value when converting to clustered bitmap
From: NeilBrown @ 2020-07-16 23:36 UTC (permalink / raw)
To: linux-raid; +Cc: Zhao Heming, neilb, song
In-Reply-To: <1594911043-16956-1-git-send-email-heming.zhao@suse.com>
[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]
On Thu, Jul 16 2020, Zhao Heming wrote:
> When array convert to clustered bitmap, the safe_mode_delay doesn't clean and vice versa.
> the /sys/block/mdX/md/safe_mode_delay keep original value after changing bitmap type.
> in safe_delay_store(), the code forbids setting mddev->safemode_delay when array is clustered.
> So in cluster-md env, the expected safemode_delay value should be 0.
>
> reproduction steps:
> ```
> node1 # mdadm --zero-superblock /dev/sd{b,c,d}
> node1 # mdadm -C /dev/md0 -b internal -e 1.2 -n 2 -l mirror /dev/sdb /dev/sdc
> node1 # cat /sys/block/md0/md/safe_mode_delay
> 0.204
> node1 # mdadm -G /dev/md0 -b none
> node1 # mdadm --grow /dev/md0 --bitmap=clustered
> node1 # cat /sys/block/md0/md/safe_mode_delay
> 0.204 <== doesn't change, should ZERO for cluster-md
>
> node1 # mdadm --zero-superblock /dev/sd{b,c,d}
> node1 # mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdb /dev/sdc
> node1 # cat /sys/block/md0/md/safe_mode_delay
> 0.000
> node1 # mdadm -G /dev/md0 -b none
> node1 # cat /sys/block/md0/md/safe_mode_delay
> 0.000 <== doesn't change, should default value
> ```
>
> Neil said md_setup_cluster/md_cluster_stop are good places to fix.
> After investigation, md_setup_cluster() is a good place for setting,
> but md_cluster_stop are not pair for restoring.
> see below flow:
> (user space)
> mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb
> mdadm --grow /dev/md0 -b none
> (kernel space)
> SET_ARRAY_INFO
> update_array_info
> + mddev->bitmap_info.nodes = 0;
> + md_cluster_ops->leave(mddev)
> + md_bitmap_destroy
> md_bitmap_free //won't trigger md_cluster_stop() because above set 0.
>
> Signed-off-by: Zhao Heming <heming.zhao@suse.com>
> ---
> v2:
> - change setting path from location_store to md_setup_cluster
> - add restoring path
>
> ---
> drivers/md/md.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index f567f53..f082f5c 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -101,6 +101,8 @@ static int remove_and_add_spares(struct mddev *mddev,
> * count by 2 for every hour elapsed between read errors.
> */
> #define MD_DEFAULT_MAX_CORRECTED_READ_ERRORS 20
> +/* Default safemode delay: 200 msec */
> +#define DEFAULT_SAFEMODE_DELAY ((200 * HZ)/1000 +1)
> /*
> * Current RAID-1,4,5 parallel reconstruction 'guaranteed speed limit'
> * is 1000 KB/sec, so the extra system load does not show up that much.
> @@ -5982,7 +5984,7 @@ int md_run(struct mddev *mddev)
> if (mddev_is_clustered(mddev))
> mddev->safemode_delay = 0;
> else
> - mddev->safemode_delay = (200 * HZ)/1000 +1; /* 200 msec delay */
> + mddev->safemode_delay = DEFAULT_SAFEMODE_DELAY;
> mddev->in_sync = 1;
> smp_wmb();
> spin_lock(&mddev->lock);
> @@ -7361,6 +7363,7 @@ static int update_array_info(struct mddev *mddev, mdu_array_info_t *info)
>
> mddev->bitmap_info.nodes = 0;
> md_cluster_ops->leave(mddev);
> + mddev->safemode_delay = DEFAULT_SAFEMODE_DELAY;
> }
> mddev_suspend(mddev);
> md_bitmap_destroy(mddev);
> @@ -8366,6 +8369,7 @@ int md_setup_cluster(struct mddev *mddev, int nodes)
> }
> spin_unlock(&pers_lock);
>
> + mddev->safemode_delay = 0;
> return md_cluster_ops->join(mddev, nodes);
->join can fail.
I'd rather you checked the error there, and only clear safemode_delay if
the return value is zero.
NeilBrown
> }
>
> --
> 1.8.3.1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH v2 net-next 3/6] net: mvneta: move mvneta_run_xdp after descriptors processing
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Move mvneta_run_xdp routine after all descriptor processing. This is a
preliminary patch to enable multi-buffers and JUMBO frames support for
XDP
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e9b3fb778d76..021419428ff8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2230,12 +2230,11 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
return ret;
}
-static int
+static void
mvneta_swbm_rx_frame(struct mvneta_port *pp,
struct mvneta_rx_desc *rx_desc,
struct mvneta_rx_queue *rxq,
struct xdp_buff *xdp,
- struct bpf_prog *xdp_prog,
struct page *page,
struct mvneta_stats *stats)
{
@@ -2244,7 +2243,6 @@ mvneta_swbm_rx_frame(struct mvneta_port *pp,
struct net_device *dev = pp->dev;
enum dma_data_direction dma_dir;
struct skb_shared_info *sinfo;
- int ret = 0;
if (MVNETA_SKB_SIZE(rx_desc->data_size) > PAGE_SIZE) {
len = MVNETA_MAX_RX_BUF_SIZE;
@@ -2270,13 +2268,8 @@ mvneta_swbm_rx_frame(struct mvneta_port *pp,
sinfo = xdp_get_shared_info_from_buff(xdp);
sinfo->nr_frags = 0;
- if (xdp_prog)
- ret = mvneta_run_xdp(pp, rxq, xdp_prog, xdp, stats);
-
rxq->left_size = rx_desc->data_size - len;
rx_desc->buf_phys_addr = 0;
-
- return ret;
}
static void
@@ -2385,20 +2378,15 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
rxq->refill_num++;
if (rx_status & MVNETA_RXD_FIRST_DESC) {
- int err;
-
/* Check errors only for FIRST descriptor */
if (rx_status & MVNETA_RXD_ERR_SUMMARY) {
mvneta_rx_error(pp, rx_desc);
goto next;
}
- err = mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf,
- xdp_prog, page, &ps);
- if (err)
- continue;
-
desc_status = rx_desc->status;
+ mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf, page,
+ &ps);
} else {
if (unlikely(!xdp_buf.data_hard_start))
continue;
@@ -2417,6 +2405,10 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
goto next;
}
+ if (xdp_prog &&
+ mvneta_run_xdp(pp, rxq, xdp_prog, &xdp_buf, &ps))
+ goto next;
+
skb = mvneta_swbm_build_skb(pp, rxq, &xdp_buf, desc_status);
if (IS_ERR(skb)) {
struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats);
--
2.26.2
^ permalink raw reply related
* [PATCH v2 net-next 5/6] net: mvneta: get rid of skb in mvneta_rx_queue
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Remove skb pointer in mvneta_rx_queue data structure since it is no
longer used
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 7746693a3de1..8b7f6fcd4cca 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -699,8 +699,6 @@ struct mvneta_rx_queue {
int first_to_refill;
u32 refill_num;
- /* pointer to uncomplete skb buffer */
- struct sk_buff *skb;
int left_size;
};
@@ -3362,9 +3360,6 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
{
mvneta_rxq_drop_pkts(pp, rxq);
- if (rxq->skb)
- dev_kfree_skb_any(rxq->skb);
-
if (rxq->descs)
dma_free_coherent(pp->dev->dev.parent,
rxq->size * MVNETA_DESC_ALIGNED_SIZE,
@@ -3377,7 +3372,6 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
rxq->descs_phys = 0;
rxq->first_to_refill = 0;
rxq->refill_num = 0;
- rxq->skb = NULL;
rxq->left_size = 0;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v2 net-next 6/6] net: mvneta: move rxq->left_size on the stack
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Allocate rxq->left_size on mvneta_rx_swbm stack since it is used just
in sw bm napi_poll
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 29 ++++++++++++---------------
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 8b7f6fcd4cca..2c9277e73cef 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -698,8 +698,6 @@ struct mvneta_rx_queue {
/* Index of first RX DMA descriptor to refill */
int first_to_refill;
u32 refill_num;
-
- int left_size;
};
static enum cpuhp_state online_hpstate;
@@ -2228,7 +2226,7 @@ static void
mvneta_swbm_rx_frame(struct mvneta_port *pp,
struct mvneta_rx_desc *rx_desc,
struct mvneta_rx_queue *rxq,
- struct xdp_buff *xdp,
+ struct xdp_buff *xdp, int *size,
struct page *page,
struct mvneta_stats *stats)
{
@@ -2262,7 +2260,7 @@ mvneta_swbm_rx_frame(struct mvneta_port *pp,
sinfo = xdp_get_shared_info_from_buff(xdp);
sinfo->nr_frags = 0;
- rxq->left_size = rx_desc->data_size - len;
+ *size = rx_desc->data_size - len;
rx_desc->buf_phys_addr = 0;
}
@@ -2270,7 +2268,7 @@ static void
mvneta_swbm_add_rx_fragment(struct mvneta_port *pp,
struct mvneta_rx_desc *rx_desc,
struct mvneta_rx_queue *rxq,
- struct xdp_buff *xdp,
+ struct xdp_buff *xdp, int *size,
struct page *page)
{
struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
@@ -2278,11 +2276,11 @@ mvneta_swbm_add_rx_fragment(struct mvneta_port *pp,
enum dma_data_direction dma_dir;
int data_len, len;
- if (rxq->left_size > MVNETA_MAX_RX_BUF_SIZE) {
+ if (*size > MVNETA_MAX_RX_BUF_SIZE) {
len = MVNETA_MAX_RX_BUF_SIZE;
data_len = len;
} else {
- len = rxq->left_size;
+ len = *size;
data_len = len - ETH_FCS_LEN;
}
dma_dir = page_pool_get_dma_dir(rxq->page_pool);
@@ -2300,7 +2298,7 @@ mvneta_swbm_add_rx_fragment(struct mvneta_port *pp,
rx_desc->buf_phys_addr = 0;
}
- rxq->left_size -= len;
+ *size -= len;
}
static struct sk_buff *
@@ -2341,7 +2339,7 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
struct mvneta_port *pp, int budget,
struct mvneta_rx_queue *rxq)
{
- int rx_proc = 0, rx_todo, refill;
+ int rx_proc = 0, rx_todo, refill, size = 0;
struct net_device *dev = pp->dev;
struct xdp_buff xdp_buf = {
.frame_sz = PAGE_SIZE,
@@ -2378,25 +2376,25 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
goto next;
}
- frame_sz = rx_desc->data_size - ETH_FCS_LEN;
+ size = rx_desc->data_size;
+ frame_sz = size - ETH_FCS_LEN;
desc_status = rx_desc->status;
- mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf, page,
- &ps);
+ mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf,
+ &size, page, &ps);
} else {
if (unlikely(!xdp_buf.data_hard_start))
continue;
mvneta_swbm_add_rx_fragment(pp, rx_desc, rxq, &xdp_buf,
- page);
+ &size, page);
} /* Middle or Last descriptor */
if (!(rx_status & MVNETA_RXD_LAST_DESC))
/* no last descriptor this time */
continue;
- if (rxq->left_size) {
- rxq->left_size = 0;
+ if (size) {
mvneta_xdp_put_buff(pp, rxq, &xdp_buf, -1, true);
goto next;
}
@@ -3372,7 +3370,6 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
rxq->descs_phys = 0;
rxq->first_to_refill = 0;
rxq->refill_num = 0;
- rxq->left_size = 0;
}
static int mvneta_txq_sw_init(struct mvneta_port *pp,
--
2.26.2
^ permalink raw reply related
* [PATCH v2 net-next 0/6] rework mvneta napi_poll loop for XDP multi-buffers
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
Rework mvneta_rx_swbm routine in order to process all rx descriptors before
building the skb or run the xdp program attached to the interface.
Introduce xdp_get_shared_info_from_{buff,frame} utility routines to get the
skb_shared_info pointer from xdp_buff or xdp_frame.
This is a preliminary series to enable multi-buffers and jumbo frames for XDP
according to [1]
[1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
Changes since v1:
- rely on skb_frag_* utility routines to access page/offset/len of the xdp multi-buffer
Lorenzo Bianconi (6):
xdp: introduce xdp_get_shared_info_from_{buff,frame} utility routines
net: mvneta: move skb build after descriptors processing
net: mvneta: move mvneta_run_xdp after descriptors processing
net: mvneta: drop all fragments in XDP_DROP
net: mvneta: get rid of skb in mvneta_rx_queue
net: mvneta: move rxq->left_size on the stack
drivers/net/ethernet/marvell/mvneta.c | 221 ++++++++++++++------------
include/net/xdp.h | 15 ++
2 files changed, 138 insertions(+), 98 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH v2 net-next 4/6] net: mvneta: drop all fragments in XDP_DROP
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Release all consumed pages if the eBPF program returns XDP_DROP for XDP
multi-buffers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 021419428ff8..7746693a3de1 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2172,13 +2172,13 @@ mvneta_xdp_xmit(struct net_device *dev, int num_frame,
static int
mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
struct bpf_prog *prog, struct xdp_buff *xdp,
- struct mvneta_stats *stats)
+ u32 frame_sz, struct mvneta_stats *stats)
{
- unsigned int len, sync;
- struct page *page;
+ unsigned int len, data_len, sync;
u32 ret, act;
len = xdp->data_end - xdp->data_hard_start - pp->rx_offset_correction;
+ data_len = xdp->data_end - xdp->data;
act = bpf_prog_run_xdp(prog, xdp);
/* Due xdp_adjust_tail: DMA sync for_device cover max len CPU touch */
@@ -2194,9 +2194,8 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
err = xdp_do_redirect(pp->dev, xdp, prog);
if (unlikely(err)) {
+ mvneta_xdp_put_buff(pp, rxq, xdp, sync, true);
ret = MVNETA_XDP_DROPPED;
- page = virt_to_head_page(xdp->data);
- page_pool_put_page(rxq->page_pool, page, sync, true);
} else {
ret = MVNETA_XDP_REDIR;
stats->xdp_redirect++;
@@ -2205,10 +2204,8 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
}
case XDP_TX:
ret = mvneta_xdp_xmit_back(pp, xdp);
- if (ret != MVNETA_XDP_TX) {
- page = virt_to_head_page(xdp->data);
- page_pool_put_page(rxq->page_pool, page, sync, true);
- }
+ if (ret != MVNETA_XDP_TX)
+ mvneta_xdp_put_buff(pp, rxq, xdp, sync, true);
break;
default:
bpf_warn_invalid_xdp_action(act);
@@ -2217,14 +2214,13 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
trace_xdp_exception(pp->dev, prog, act);
/* fall through */
case XDP_DROP:
- page = virt_to_head_page(xdp->data);
- page_pool_put_page(rxq->page_pool, page, sync, true);
+ mvneta_xdp_put_buff(pp, rxq, xdp, sync, true);
ret = MVNETA_XDP_DROPPED;
stats->xdp_drop++;
break;
}
- stats->rx_bytes += xdp->data_end - xdp->data;
+ stats->rx_bytes += frame_sz + xdp->data_end - xdp->data - data_len;
stats->rx_packets++;
return ret;
@@ -2355,7 +2351,7 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
};
struct mvneta_stats ps = {};
struct bpf_prog *xdp_prog;
- u32 desc_status;
+ u32 desc_status, frame_sz;
/* Get number of received packets */
rx_todo = mvneta_rxq_busy_desc_num_get(pp, rxq);
@@ -2384,7 +2380,9 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
goto next;
}
+ frame_sz = rx_desc->data_size - ETH_FCS_LEN;
desc_status = rx_desc->status;
+
mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf, page,
&ps);
} else {
@@ -2406,7 +2404,7 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
}
if (xdp_prog &&
- mvneta_run_xdp(pp, rxq, xdp_prog, &xdp_buf, &ps))
+ mvneta_run_xdp(pp, rxq, xdp_prog, &xdp_buf, frame_sz, &ps))
goto next;
skb = mvneta_swbm_build_skb(pp, rxq, &xdp_buf, desc_status);
--
2.26.2
^ permalink raw reply related
* [PATCH v2 net-next 2/6] net: mvneta: move skb build after descriptors processing
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Move skb build after all descriptors processing. This is a preliminary
patch to enable multi-buffers and JUMBO frames support for XDP.
Introduce mvneta_xdp_put_buff routine to release all pages used by a
XDP multi-buffer
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/marvell/mvneta.c | 158 ++++++++++++++++----------
1 file changed, 101 insertions(+), 57 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 7191902f6cfe..e9b3fb778d76 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2026,6 +2026,20 @@ int mvneta_rx_refill_queue(struct mvneta_port *pp, struct mvneta_rx_queue *rxq)
return i;
}
+static void
+mvneta_xdp_put_buff(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
+ struct xdp_buff *xdp, int sync_len, bool napi)
+{
+ struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
+ int i;
+
+ page_pool_put_page(rxq->page_pool, virt_to_head_page(xdp->data),
+ sync_len, napi);
+ for (i = 0; i < sinfo->nr_frags; i++)
+ page_pool_put_full_page(rxq->page_pool,
+ skb_frag_page(&sinfo->frags[i]), napi);
+}
+
static int
mvneta_xdp_submit_frame(struct mvneta_port *pp, struct mvneta_tx_queue *txq,
struct xdp_frame *xdpf, bool dma_map)
@@ -2229,6 +2243,7 @@ mvneta_swbm_rx_frame(struct mvneta_port *pp,
int data_len = -MVNETA_MH_SIZE, len;
struct net_device *dev = pp->dev;
enum dma_data_direction dma_dir;
+ struct skb_shared_info *sinfo;
int ret = 0;
if (MVNETA_SKB_SIZE(rx_desc->data_size) > PAGE_SIZE) {
@@ -2252,35 +2267,13 @@ mvneta_swbm_rx_frame(struct mvneta_port *pp,
xdp->data_end = xdp->data + data_len;
xdp_set_data_meta_invalid(xdp);
- if (xdp_prog) {
- ret = mvneta_run_xdp(pp, rxq, xdp_prog, xdp, stats);
- if (ret)
- goto out;
- }
-
- rxq->skb = build_skb(xdp->data_hard_start, PAGE_SIZE);
- if (unlikely(!rxq->skb)) {
- struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats);
+ sinfo = xdp_get_shared_info_from_buff(xdp);
+ sinfo->nr_frags = 0;
- netdev_err(dev, "Can't allocate skb on queue %d\n", rxq->id);
-
- u64_stats_update_begin(&stats->syncp);
- stats->es.skb_alloc_error++;
- stats->rx_dropped++;
- u64_stats_update_end(&stats->syncp);
-
- return -ENOMEM;
- }
- page_pool_release_page(rxq->page_pool, page);
-
- skb_reserve(rxq->skb,
- xdp->data - xdp->data_hard_start);
- skb_put(rxq->skb, xdp->data_end - xdp->data);
- mvneta_rx_csum(pp, rx_desc->status, rxq->skb);
+ if (xdp_prog)
+ ret = mvneta_run_xdp(pp, rxq, xdp_prog, xdp, stats);
rxq->left_size = rx_desc->data_size - len;
-
-out:
rx_desc->buf_phys_addr = 0;
return ret;
@@ -2290,8 +2283,10 @@ static void
mvneta_swbm_add_rx_fragment(struct mvneta_port *pp,
struct mvneta_rx_desc *rx_desc,
struct mvneta_rx_queue *rxq,
+ struct xdp_buff *xdp,
struct page *page)
{
+ struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
struct net_device *dev = pp->dev;
enum dma_data_direction dma_dir;
int data_len, len;
@@ -2307,18 +2302,53 @@ mvneta_swbm_add_rx_fragment(struct mvneta_port *pp,
dma_sync_single_for_cpu(dev->dev.parent,
rx_desc->buf_phys_addr,
len, dma_dir);
- if (data_len > 0) {
- /* refill descriptor with new buffer later */
- skb_add_rx_frag(rxq->skb,
- skb_shinfo(rxq->skb)->nr_frags,
- page, pp->rx_offset_correction, data_len,
- PAGE_SIZE);
- }
- page_pool_release_page(rxq->page_pool, page);
- rx_desc->buf_phys_addr = 0;
+
+ if (data_len > 0 && sinfo->nr_frags < MAX_SKB_FRAGS) {
+ skb_frag_t *frag = &sinfo->frags[sinfo->nr_frags];
+
+ skb_frag_off_set(frag, pp->rx_offset_correction);
+ skb_frag_size_set(frag, data_len);
+ __skb_frag_set_page(frag, page);
+ sinfo->nr_frags++;
+
+ rx_desc->buf_phys_addr = 0;
+ }
rxq->left_size -= len;
}
+static struct sk_buff *
+mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
+ struct xdp_buff *xdp, u32 desc_status)
+{
+ struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
+ int i, num_frags = sinfo->nr_frags;
+ skb_frag_t frags[MAX_SKB_FRAGS];
+ struct sk_buff *skb;
+
+ memcpy(frags, sinfo->frags, sizeof(skb_frag_t) * num_frags);
+
+ skb = build_skb(xdp->data_hard_start, PAGE_SIZE);
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ page_pool_release_page(rxq->page_pool, virt_to_page(xdp->data));
+
+ skb_reserve(skb, xdp->data - xdp->data_hard_start);
+ skb_put(skb, xdp->data_end - xdp->data);
+ mvneta_rx_csum(pp, desc_status, skb);
+
+ for (i = 0; i < num_frags; i++) {
+ struct page *page = skb_frag_page(&frags[i]);
+
+ skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
+ page, skb_frag_off(&frags[i]),
+ skb_frag_size(&frags[i]), PAGE_SIZE);
+ page_pool_release_page(rxq->page_pool, page);
+ }
+
+ return skb;
+}
+
/* Main rx processing when using software buffer management */
static int mvneta_rx_swbm(struct napi_struct *napi,
struct mvneta_port *pp, int budget,
@@ -2326,22 +2356,25 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
{
int rx_proc = 0, rx_todo, refill;
struct net_device *dev = pp->dev;
+ struct xdp_buff xdp_buf = {
+ .frame_sz = PAGE_SIZE,
+ .rxq = &rxq->xdp_rxq,
+ };
struct mvneta_stats ps = {};
struct bpf_prog *xdp_prog;
- struct xdp_buff xdp_buf;
+ u32 desc_status;
/* Get number of received packets */
rx_todo = mvneta_rxq_busy_desc_num_get(pp, rxq);
rcu_read_lock();
xdp_prog = READ_ONCE(pp->xdp_prog);
- xdp_buf.rxq = &rxq->xdp_rxq;
- xdp_buf.frame_sz = PAGE_SIZE;
/* Fairness NAPI loop */
while (rx_proc < budget && rx_proc < rx_todo) {
struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq);
u32 rx_status, index;
+ struct sk_buff *skb;
struct page *page;
index = rx_desc - rxq->descs;
@@ -2357,21 +2390,21 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
/* Check errors only for FIRST descriptor */
if (rx_status & MVNETA_RXD_ERR_SUMMARY) {
mvneta_rx_error(pp, rx_desc);
- /* leave the descriptor untouched */
- continue;
+ goto next;
}
err = mvneta_swbm_rx_frame(pp, rx_desc, rxq, &xdp_buf,
xdp_prog, page, &ps);
if (err)
continue;
+
+ desc_status = rx_desc->status;
} else {
- if (unlikely(!rxq->skb)) {
- pr_debug("no skb for rx_status 0x%x\n",
- rx_status);
+ if (unlikely(!xdp_buf.data_hard_start))
continue;
- }
- mvneta_swbm_add_rx_fragment(pp, rx_desc, rxq, page);
+
+ mvneta_swbm_add_rx_fragment(pp, rx_desc, rxq, &xdp_buf,
+ page);
} /* Middle or Last descriptor */
if (!(rx_status & MVNETA_RXD_LAST_DESC))
@@ -2379,27 +2412,38 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
continue;
if (rxq->left_size) {
- pr_err("get last desc, but left_size (%d) != 0\n",
- rxq->left_size);
- dev_kfree_skb_any(rxq->skb);
rxq->left_size = 0;
- rxq->skb = NULL;
- continue;
+ mvneta_xdp_put_buff(pp, rxq, &xdp_buf, -1, true);
+ goto next;
}
- ps.rx_bytes += rxq->skb->len;
- ps.rx_packets++;
+ skb = mvneta_swbm_build_skb(pp, rxq, &xdp_buf, desc_status);
+ if (IS_ERR(skb)) {
+ struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats);
- /* Linux processing */
- rxq->skb->protocol = eth_type_trans(rxq->skb, dev);
+ mvneta_xdp_put_buff(pp, rxq, &xdp_buf, -1, true);
+
+ u64_stats_update_begin(&stats->syncp);
+ stats->es.skb_alloc_error++;
+ stats->rx_dropped++;
+ u64_stats_update_end(&stats->syncp);
+
+ goto next;
+ }
- napi_gro_receive(napi, rxq->skb);
+ ps.rx_bytes += skb->len;
+ ps.rx_packets++;
- /* clean uncomplete skb pointer in queue */
- rxq->skb = NULL;
+ skb->protocol = eth_type_trans(skb, dev);
+ napi_gro_receive(napi, skb);
+next:
+ xdp_buf.data_hard_start = NULL;
}
rcu_read_unlock();
+ if (xdp_buf.data_hard_start)
+ mvneta_xdp_put_buff(pp, rxq, &xdp_buf, -1, true);
+
if (ps.xdp_redirect)
xdp_do_flush_map();
--
2.26.2
^ permalink raw reply related
* [PATCH v2 net-next 1/6] xdp: introduce xdp_get_shared_info_from_{buff,frame} utility routines
From: Lorenzo Bianconi @ 2020-07-16 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, bpf, kuba, ilias.apalodimas, lorenzo.bianconi, brouer,
echaudro, sameehj
In-Reply-To: <cover.1594936660.git.lorenzo@kernel.org>
Introduce xdp_get_shared_info_from_{buff,frame} utility routines to get
skb_shared_info from xdp buffer/frame pointer.
xdp_get_shared_info_from_{buff,frame} will be used to implement xdp
multi-buffer support
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
include/net/xdp.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/net/xdp.h b/include/net/xdp.h
index 609f819ed08b..d3005bef812f 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -85,6 +85,12 @@ struct xdp_buff {
((xdp)->data_hard_start + (xdp)->frame_sz - \
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+static inline struct skb_shared_info *
+xdp_get_shared_info_from_buff(struct xdp_buff *xdp)
+{
+ return (struct skb_shared_info *)xdp_data_hard_end(xdp);
+}
+
struct xdp_frame {
void *data;
u16 len;
@@ -98,6 +104,15 @@ struct xdp_frame {
struct net_device *dev_rx; /* used by cpumap */
};
+static inline struct skb_shared_info *
+xdp_get_shared_info_from_frame(struct xdp_frame *frame)
+{
+ void *data_hard_start = frame->data - frame->headroom - sizeof(*frame);
+
+ return (struct skb_shared_info *)(data_hard_start + frame->frame_sz -
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
+}
+
/* Clear kernel pointers in xdp_frame */
static inline void xdp_scrub_frame(struct xdp_frame *frame)
{
--
2.26.2
^ permalink raw reply related
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
From: Patchwork @ 2020-07-16 23:34 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <20200716232900.28414-1-manasi.d.navare@intel.com>
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
URL : https://patchwork.freedesktop.org/series/79569/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Fuego] Fuego on Debian 10 / Jenkins 2.235.1 (and python 3.7 support)
From: Bird, Tim @ 2020-07-16 23:34 UTC (permalink / raw)
To: daniel.sangorrin@toshiba.co.jp,
laszlo.sitzer@native-instruments.de,
fuego@lists.linuxfoundation.org
In-Reply-To: <OSBPR01MB2053D79995D5AEBE6F96A5A2D07F0@OSBPR01MB2053.jpnprd01.prod.outlook.com>
> -----Original Message-----
> From: daniel.sangorrin@toshiba.co.jp
>
> Tim,
>
> A bit related to this. I noticed that a lot of the old Yocto/OE toolchains do not work on Fuego because it uses newer versions of Debian. I
> wonder if we should keep Fuego working on multiple versions of Debian next time.
I think that's probably a good idea. I'm not sure what issues will arise during an
distro upgrade, but some always do. We should keep in mind backwards
compatibility with old Debian as well as old Jenkins. I'm not sure if those
need to be coupled or not, but I don't want the matrix of supported things
to get too big. :-)
-- Tim
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
From: Patchwork @ 2020-07-16 23:33 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <20200716232900.28414-1-manasi.d.navare@intel.com>
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
URL : https://patchwork.freedesktop.org/series/79569/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e44cd55cc41 drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 17 lines checked
745bd4981bd6 drm/i915/display/dp: Hacks for testing link training fail errors
-:47: ERROR:SPACING: space required after that close brace '}'
#47: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:418:
+ }/* else if (intel_dp_get_link_train_fallback_values(intel_dp,
-:52: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line
#52: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:422:
+ }*/
total: 1 errors, 1 warnings, 0 checks, 34 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
From: Sowjanya Komatineni @ 2020-07-16 22:49 UTC (permalink / raw)
To: Dmitry Osipenko, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: sboyd, gregkh, linux-media, devicetree, linux-tegra, linux-kernel,
linux-i2c
In-Reply-To: <c4945c77-5de1-e9b1-9f4f-cdd78bca18c7@gmail.com>
On 7/16/20 2:18 PM, Dmitry Osipenko wrote:
> 17.07.2020 00:09, Sowjanya Komatineni пишет:
>> On 7/16/20 1:38 PM, Dmitry Osipenko wrote:
>>> 15.07.2020 07:20, Sowjanya Komatineni пишет:
>>>> SW can trigger MIPI pads calibration any time after power on
>>>> but calibration results will be latched and applied to the pads
>>>> by MIPI CAL unit only when the link is in LP-11 state and then
>>>> status register will be updated.
>>>>
>>>> For CSI, trigger of pads calibration happen during CSI stream
>>>> enable where CSI receiver is kept ready prior to sensor or CSI
>>>> transmitter stream start.
>>>>
>>>> So, pads may not be in LP-11 at this time and waiting for the
>>>> calibration to be done immediate after calibration start will
>>>> result in timeout.
>>>>
>>>> This patch splits tegra_mipi_calibrate() and tegra_mipi_wait()
>>>> so triggering for calibration and waiting for it to complete can
>>>> happen at different stages.
>>>>
>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>> ---
>>> ...
>>>> int tegra_mipi_calibrate(struct tegra_mipi_device *device)
>>>> {
>>>> @@ -370,12 +381,10 @@ int tegra_mipi_calibrate(struct
>>>> tegra_mipi_device *device)
>>>> value |= MIPI_CAL_CTRL_START;
>>>> tegra_mipi_writel(device->mipi, value, MIPI_CAL_CTRL);
>>>> - err = tegra_mipi_wait(device->mipi);
>>> Doesn't MIPI clock need to be enabled during of the calibration process?
>> MIPI clock is already enabled in tegra_mipi_calibrate
>>>> mutex_unlock(&device->mipi->lock);
>>>> clk_disable(device->mipi->clk);
> What keeps MIPI clock enabled after completion of the
> tegra_mipi_calibrate() invocation?
MIPI clock is disabled at end of tegra_mipi_calibrate and is re-enabled
during tegra_mipi_wait.
I think I should fix this to keep the clock enabled till calibration
results are latched.
All consumers of tegra_mipi_calibrate() will call tegra_mipi_wait().
So will remove clk_disable mipi clk at end of tegra_mipi_calibrate() and
clk_enable mipi_clk at beginning of tegra_mipi_wait()
>
>>>> - return err;
>>>> + return 0;
>>>> }
>>>> EXPORT_SYMBOL(tegra_mipi_calibrate);
^ permalink raw reply
* [PATCH] dt-bindings: ingenic,pinctrl: Support pinmux/pinconf nodes
From: Paul Cercueil @ 2020-07-16 23:32 UTC (permalink / raw)
To: Rob Herring, Linus Walleij
Cc: od, linux-gpio, devicetree, linux-kernel, Paul Cercueil
Add YAML to describe the pinmux/pinconf sub-nodes of the pinctrl IP on
Ingenic SoCs.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
In-Reply-To: CAL_Jsq+nHZsbOMPpXC7NWp1etgVL57Q+o=gr6BJ6ijAq1pLJUw@mail.gmail.com
---
.../bindings/pinctrl/ingenic,pinctrl.yaml | 41 ++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
index adf462cc2737..9d374f55ebb1 100644
--- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
@@ -110,7 +110,46 @@ required:
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+additionalProperties:
+ anyOf:
+ - type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ phandle: true
+ function: true
+ groups: true
+ pins: true
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ output-low: true
+ output-high: true
+ additionalProperties: false
+
+ - type: object
+ properties:
+ phandle: true
+ additionalProperties:
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ phandle: true
+ function: true
+ groups: true
+ pins: true
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ output-low: true
+ output-high: true
+ additionalProperties: false
+
examples:
- |
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v1 2/3] dt-bindings: media: imx274: Add optional xclk and supplies
From: Sowjanya Komatineni @ 2020-07-16 23:35 UTC (permalink / raw)
To: Luca Ceresoli, thierry.reding, jonathanh, frankc, hverkuil, leonl,
robh+dt, lgirdwood, broonie
Cc: linux-media, devicetree, linux-kernel
In-Reply-To: <1df13fad-b5ce-3889-c240-3411e97598d2@lucaceresoli.net>
On 7/15/20 11:50 PM, Luca Ceresoli wrote:
> Hi Sowjanya,
>
> On 15/07/20 06:24, Sowjanya Komatineni wrote:
>> This patch adds IMX274 optional external clock input and voltage
>> supplies to device tree bindings.
>>
>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>> ---
>> Documentation/devicetree/bindings/media/i2c/imx274.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt b/Documentation/devicetree/bindings/media/i2c/imx274.txt
>> index 80f2e89..ee427f5 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/imx274.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt
>> @@ -13,6 +13,11 @@ Required Properties:
>>
>> Optional Properties:
>> - reset-gpios: Sensor reset GPIO
>> +- clocks: Reference to the xclk clock.
>> +- clock-names: Should be "xclk".
> Not sure where the "xclk" name comes from, the datasheet I have calls
> the pin "CKIN". Maybe using the same name as the datasheet is better?
>
> Other than that looks good.
Thanks Luca. Using xclk as its external clock to IMX274.
Datasheet uses it as INCK. Will update in v2 to use "INCK" as referred
in its datasheet.
^ permalink raw reply
* Re: [PATCH 01/11] xfs: drop the type parameter from xfs_dquot_verify
From: Dave Chinner @ 2020-07-16 23:32 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <159488192588.3813063.14434497860489645794.stgit@magnolia>
On Wed, Jul 15, 2020 at 11:45:25PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> xfs_qm_reset_dqcounts (i.e. quotacheck) is the only xfs_dqblk_verify
> caller that actually knows the specific quota type that it's looking
> for. Since everything else just pass in type==0 (including the buffer
> verifier), drop the parameter and open-code the check like
> xfs_dquot_from_disk already does.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Looks fine.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* + mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2.patch added to -mm tree
From: Andrew Morton @ 2020-07-16 23:32 UTC (permalink / raw)
To: cuibixuan, guro, mm-commits, sfr
In-Reply-To: <20200703151445.b6a0cfee402c7c5c4651f1b1@linux-foundation.org>
The patch titled
Subject: mm/percpu: fix 'defined but not used' warning
has been added to the -mm tree. Its filename is
mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Bixuan Cui <cuibixuan@huawei.com>
Subject: mm/percpu: fix 'defined but not used' warning
Gcc report the following warning without CONFIG_MEMCG_KMEM:
mm/percpu-internal.h:145:29: warning: 'pcpu_chunk_type' defined
but not used [-Wunused-function]
static enum pcpu_chunk_type pcpu_chunk_type(struct pcpu_chunk *chunk)
^~~~~~~~~~~~~~~
Add 'inline' to pcpu_chunk_type(),pcpu_is_memcg_chunk() and
pcpu_chunk_list() to clear warning.
Link: http://lkml.kernel.org/r/6d41b939-a741-b521-a7a2-e7296ec16219@huawei.com
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/percpu-internal.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/mm/percpu-internal.h~mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2
+++ a/mm/percpu-internal.h
@@ -129,31 +129,31 @@ static inline int pcpu_chunk_map_bits(st
}
#ifdef CONFIG_MEMCG_KMEM
-static enum pcpu_chunk_type pcpu_chunk_type(struct pcpu_chunk *chunk)
+static inline enum pcpu_chunk_type pcpu_chunk_type(struct pcpu_chunk *chunk)
{
if (chunk->obj_cgroups)
return PCPU_CHUNK_MEMCG;
return PCPU_CHUNK_ROOT;
}
-static bool pcpu_is_memcg_chunk(enum pcpu_chunk_type chunk_type)
+static inline bool pcpu_is_memcg_chunk(enum pcpu_chunk_type chunk_type)
{
return chunk_type == PCPU_CHUNK_MEMCG;
}
#else
-static enum pcpu_chunk_type pcpu_chunk_type(struct pcpu_chunk *chunk)
+static inline enum pcpu_chunk_type pcpu_chunk_type(struct pcpu_chunk *chunk)
{
return PCPU_CHUNK_ROOT;
}
-static bool pcpu_is_memcg_chunk(enum pcpu_chunk_type chunk_type)
+static inline bool pcpu_is_memcg_chunk(enum pcpu_chunk_type chunk_type)
{
return false;
}
#endif
-static struct list_head *pcpu_chunk_list(enum pcpu_chunk_type chunk_type)
+static inline struct list_head *pcpu_chunk_list(enum pcpu_chunk_type chunk_type)
{
return &pcpu_chunk_lists[pcpu_nr_slots *
pcpu_is_memcg_chunk(chunk_type)];
_
Patches currently in -mm which might be from cuibixuan@huawei.com are
mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-2.patch
^ permalink raw reply
* [GIT PULL] mediatek drm next for 5.9
From: Chun-Kuang Hu @ 2020-07-16 23:31 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, linux-mediatek
Cc: Enric Balletbo i Serra
Hi, Dave & Daniel:
This include converting mtk_dsi to drm_bridge API.
Regards,
Chun-Kuang.
The following changes since commit 5ab546f5e6309373aef01a8d398e163ab7a78431:
drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05 06:39:21 +0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-5.9
for you to fetch changes up to a9d9fea74be285a2885d8f3395042cc4dde27e6a:
drm/mediatek: mtk_dsi: Create connector for bridges (2020-07-05 08:06:28 +0800)
----------------------------------------------------------------
Mediatek DRM Next for Linux 5.9
----------------------------------------------------------------
Enric Balletbo i Serra (5):
drm/mediatek: mtk_dsi: Rename bridge to next_bridge
drm/mediatek: mtk_dsi: Convert to bridge driver
drm/mediatek: mtk_dsi: Use simple encoder
drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
drm/mediatek: mtk_dsi: Create connector for bridges
drivers/gpu/drm/mediatek/mtk_dsi.c | 269 ++++++++++++++++++++++++-----------------------------------------------------
1 file changed, 84 insertions(+), 185 deletions(-)
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [GIT PULL] mediatek drm next for 5.9
From: Chun-Kuang Hu @ 2020-07-16 23:31 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel, linux-mediatek
Cc: Enric Balletbo i Serra
Hi, Dave & Daniel:
This include converting mtk_dsi to drm_bridge API.
Regards,
Chun-Kuang.
The following changes since commit 5ab546f5e6309373aef01a8d398e163ab7a78431:
drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05 06:39:21 +0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-5.9
for you to fetch changes up to a9d9fea74be285a2885d8f3395042cc4dde27e6a:
drm/mediatek: mtk_dsi: Create connector for bridges (2020-07-05 08:06:28 +0800)
----------------------------------------------------------------
Mediatek DRM Next for Linux 5.9
----------------------------------------------------------------
Enric Balletbo i Serra (5):
drm/mediatek: mtk_dsi: Rename bridge to next_bridge
drm/mediatek: mtk_dsi: Convert to bridge driver
drm/mediatek: mtk_dsi: Use simple encoder
drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
drm/mediatek: mtk_dsi: Create connector for bridges
drivers/gpu/drm/mediatek/mtk_dsi.c | 269 ++++++++++++++++++++++++-----------------------------------------------------
1 file changed, 84 insertions(+), 185 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* What's cooking in git.git (Jul 2020, #03; Thu, 16)
From: Junio C Hamano @ 2020-07-16 23:30 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed
with '+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git 2.28-rc1 has not been tagged yet. Hopefully the three patches
in jn/v0-with-extensions-fix can gain enough support to get merged
tomorrow for the real -rc1.
As I promised, I am not paying much attention to topics that are not
relevant to the upcoming release, so the comments on the topics may
be left stale in the below.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to 'master']
* ct/diff-with-merge-base-clarification (2020-07-13) 2 commits
(merged to 'next' on 2020-07-15 at 041807cbbd)
+ git-diff.txt: reorder possible usages
+ git-diff.txt: don't mark required argument as optional
Doc update.
* sg/commit-graph-progress-fix (2020-07-09) 2 commits
(merged to 'next' on 2020-07-09 at 3a9f916ca4)
+ commit-graph: fix "Writing out commit graph" progress counter
+ commit-graph: fix progress of reachable commits
The code to produce progress output from "git commit-graph --write"
had a few breakages, which have been fixed.
* ta/wait-on-aliased-commands-upon-signal (2020-07-07) 2 commits
(merged to 'next' on 2020-07-09 at de8bde9182)
+ Wait for child on signal death for aliases to externals
+ Wait for child on signal death for aliases to builtins
When an aliased command, whose output is piped to a pager by git,
gets killed by a signal, the pager got into a funny state, which
has been corrected (again).
* tb/commit-graph-no-check-oids (2020-07-15) 1 commit
(merged to 'next' on 2020-07-15 at d97ae59198)
+ commit-graph: fix "Collecting commits from input" progress line
Fix to the code to produce progress bar, which is new in the
upcoming release.
--------------------------------------------------
[New Topics]
* jn/v0-with-extensions-fix (2020-07-16) 3 commits
(merged to 'next' on 2020-07-16 at 85f634d5a6)
+ verify_repository_format(): complain about new extensions in v0 repo
+ repository: allow repository format upgrade with extensions
+ Revert "check_repository_format_gently(): refuse extensions for old repositories"
In 2.28-rc0, we corrected a bug that some repository extensions are
honored by mistake even in a version 0 repositories (these
configuration variables in extensions.* namespace were supposed to
have special meaning in repositories whose version numbers are 1 or
higher), but this was a bit too big a change.
Will merge to 'master' before -rc1.
* bc/sha-256-part-3 (2020-07-15) 39 commits
- t: remove test_oid_init in tests
- docs: add documentation for extensions.objectFormat
- ci: run tests with SHA-256
- t: make SHA1 prerequisite depend on default hash
- t: allow testing different hash algorithms via environment
- t: add test_oid option to select hash algorithm
- Enable SHA-256 support by default
- setup: add support for reading extensions.objectformat
- bundle: add new version for use with SHA-256
- builtin/verify-pack: implement an --object-format option
- http-fetch: set up git directory before parsing pack hashes
- t0410: mark test with SHA1 prerequisite
- t5308: make test work with SHA-256
- t9700: make hash size independent
- t9500: ensure that algorithm info is preserved in config
- t9350: make hash size independent
- t9301: make hash size independent
- t9300: use $ZERO_OID instead of hard-coded object ID
- t9300: abstract away SHA-1-specific constants
- t8011: make hash size independent
- t8003: make hash size independent
- t8002: make hash size independent
- t7508: use $ZERO_OID instead of hard-coded constant
- t7506: avoid checking for SHA-1-specific constants
- t7405: make hash size independent
- t7400: make hash size independent
- t7102: abstract away SHA-1-specific constants
- t7201: abstract away SHA-1-specific constants
- t7063: make hash size independent
- t7003: compute appropriate length constant
- t6501: avoid hard-coded objects
- t6500: specify test values for SHA-256
- t6301: make hash size independent
- t6101: make hash size independent
- t6100: make hash size independent
- t3404: prepare 'short SHA-1 collision' tests for SHA-256
- t3305: make hash agnostic
- t1001: use $ZERO_OID
- t: make test-bloom initialize repository
The final leg of SHA-256 transition.
* jk/tests-timestamp-fix (2020-07-15) 6 commits
(merged to 'next' on 2020-07-16 at 2c69e97b92)
+ t9100: stop depending on commit timestamps
(merged to 'next' on 2020-07-14 at 66ee0e6b45)
+ test-lib: set deterministic default author/committer date
+ t9100: explicitly unset GIT_COMMITTER_DATE
+ t5539: make timestamp requirements more explicit
+ t9700: loosen ident timezone regex
(merged to 'next' on 2020-07-09 at 633bcd552f)
+ t6000: use test_tick consistently
The test framework has been updated so that most tests will run
with predictable (artificial) timestamps.
Will cook in 'next'.
* jc/no-update-fetch-head (2020-07-13) 1 commit
- fetch: optionally allow disabling FETCH_HEAD update
"git fetch" learned the "--[no-]write-fetch-head" option to
optionally stop describing what was fetched in FETCH_HEAD.
* mp/complete-show-color-moved (2020-07-15) 1 commit
- completion: add show --color-moved[-ws]
Command line completion (in contrib/) update.
* hn/reftable-prep-part-2 (2020-07-16) 3 commits
- Make HEAD a PSEUDOREF rather than PER_WORKTREE.
- Modify pseudo refs through ref backend storage
- t1400: use git rev-parse for testing PSEUDOREF existence
(this branch uses hn/reftable.)
Further preliminary change to refs API.
* jt/avoid-lazy-fetching-upon-have-check (2020-07-16) 1 commit
- upload-pack: do not lazy-fetch "have" objects
Fetching from a lazily cloned repository resulted at the server
side in attempts to lazy fetch objects that the client side has,
many of which will not be available from the third-party anyway.
Will merge to 'next'.
* rc/add-index-entry-optim-fix (2020-07-16) 1 commit
- read-cache: remove bogus shortcut
Fix to an ancient bug caused by an over-eager attempt for
optimization.
--------------------------------------------------
[Stalled]
* jx/proc-receive-hook (2020-05-18) 11 commits
- doc: add documentation for the proc-receive hook
- transport: parse report options for tracking refs
- t5411: test updates of remote-tracking branches
- receive-pack: new config receive.procReceiveRefs
- refs.c: refactor to reuse ref_is_hidden()
- receive-pack: feed report options to post-receive
- doc: add document for capability report-status-v2
- New capability "report-status-v2" for git-push
- receive-pack: add new proc-receive hook
- t5411: add basic test cases for proc-receive hook
- transport: not report a non-head push as a branch
"git receive-pack" that accepts requests by "git push" learned to
outsource most of the ref updates to the new "proc-receive" hook.
Needs review.
* mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits
- submodule: use submodule repository when preparing summary
- revision: use repository from rev_info when parsing commits
"git diff/show" on a change that involves a submodule used to read
the information on commits in the submodule from a wrong repository
and gave a wrong information when the commit-graph is involved.
Needs tests.
* dr/push-remoteref-fix (2020-04-23) 1 commit
- remote.c: fix handling of %(push:remoteref)
The "%(push:remoteref)" placeholder in the "--format=" argument of
"git format-patch" (and friends) only showed what got explicitly
configured, not what ref at the receiving end would be updated when
"git push" was used, as it ignored the default behaviour (e.g. update
the same ref as the source).
Expecting a reroll.
cf. <20200416152145.wp2zeibxmuyas6y6@feanor>
* mr/bisect-in-c-2 (2020-07-08) 13 commits
. bisect--helper: retire `--bisect-autostart` subcommand
. bisect--helper: retire `--write-terms` subcommand
. bisect--helper: retire `--check-expected-revs` subcommand
. bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C
. bisect--helper: retire `--next-all` subcommand
. bisect--helper: retire `--bisect-clean-state` subcommand
. bisect--helper: finish porting `bisect_start()` to C
. bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
. bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'
. bisect--helper: reimplement `bisect_autostart` shell function in C
. bisect--helper: introduce new `write_in_file()` function
. bisect--helper: use '-res' in 'cmd_bisect__helper' return
. bisect--helper: BUG() in cmd_*() on invalid subcommand
Rewrite of the remainder of "git bisect" script in C continues.
Needs more work.
* mk/use-size-t-in-zlib (2018-10-15) 1 commit
- zlib.c: use size_t for size
The wrapper to call into zlib followed our long tradition to use
"unsigned long" for sizes of regions in memory, which have been
updated to use "size_t".
--------------------------------------------------
[Cooking]
* dl/test-must-fail-fixes-6 (2020-07-07) 6 commits
- test-lib-functions: restrict test_must_fail usage
- t9400: don't use test_must_fail with cvs
- t9834: remove use of `test_might_fail p4`
- t7107: don't use test_must_fail()
- t5324: reorder `run_with_limited_open_files test_might_fail`
- t3701: stop using `env` in force_color()
Dev support to limit the use of test_must_fail to only git commands.
* ds/maintenance (2020-07-07) 21 commits
- midx: use start_delayed_progress()
- maintenance: add pack-files auto condition
- maintenance: create auto condition for loose-objects
- maintenance: add auto condition for commit-graph task
- maintenance: use pointers to check --auto
- maintenance: create maintenance.<task>.enabled config
- maintenance: auto-size pack-files batch
- maintenance: add pack-files task
- maintenance: add loose-objects task
- maintenance: add fetch task
- maintenance: take a lock on the objects directory
- maintenance: add --task option
- maintenance: add commit-graph task
- maintenance: initialize task array and hashmap
- maintenance: replace run_auto_gc()
- maintenance: add --quiet option
- maintenance: create basic maintenance runner
- gc: drop the_repository in log location
- gc: use repo config
- gc: use repository in too_many_loose_objects()
- gc: use the_repository less often
A "git gc"'s big brother has been introduced to take care of more
repository maintenance tasks, not limited to the object database
cleaning.
* bw/fail-cloning-into-non-empty (2020-07-10) 1 commit
(merged to 'next' on 2020-07-14 at a52b5ce7ab)
+ git clone: don't clone into non-empty directory
"git clone --separate-git-dir=$elsewhere" used to stomp on the
contents of the existing directory $elsewhere, which has been
taught to fail when $elsewhere is not an empty directory.
Will cook in 'next'.
* cc/pretty-contents-size (2020-07-16) 3 commits
- ref-filter: add support for %(contents:size)
- t6300: test refs pointing to tree and blob
- Documentation: clarify %(contents:XXXX) doc
"git for-each-ref --format=<>" learned %(contents:size).
Will merge to 'next'.
* ls/mergetool-meld-auto-merge (2020-07-12) 2 commits
- SQUASH???
- Support auto-merge for meld to follow the vim-diff behavior
The 'meld' backend of the "git mergetool" learned to give the
underlying 'meld' the '--auto-merge' option, which would help
reduce the amount of text that requires manual merging.
* pb/log-rev-list-doc (2020-07-08) 6 commits
(merged to 'next' on 2020-07-14 at f1104dfb77)
+ git-log.txt: include rev-list-description.txt
+ git-rev-list.txt: move description to separate file
+ git-rev-list.txt: tweak wording in set operations
+ git-rev-list.txt: fix Asciidoc syntax
+ revisions.txt: describe 'rev1 rev2 ...' meaning for ranges
+ git-log.txt: add links to 'rev-list' and 'diff' docs
"git help log" has been enhanced by sharing more material from the
documentation for the underlying "git rev-list" command.
Will cook in 'next'.
* tb/upload-pack-filters (2020-07-06) 4 commits
- upload-pack.c: introduce 'uploadpack.filter.tree.maxDepth'
- upload-pack.c: pass 'struct list_objects_filter_options *'
- upload-pack.c: allow banning certain object filter(s)
- list_objects_filter_options: introduce 'list_object_filter_config_name'
The component to respond to "git fetch" request is made more
configurable to selectively allow or reject object filtering
specification used for partial cloning.
Waiting for reviews to settle.
cf. <cover.1593720075.git.me@ttaylorr.com>
cf. <20200710022609.GC39052@syl.lan>
* mt/hash-to-hex-thread-safety (2020-06-26) 2 commits
- hex: make hash_to_hex_algop() and friends thread-safe
- compat/win32/pthread: add pthread_once()
hash_to_hex() used a set of rotating static buffers, which was not
safe to use in a threaded environment. This has been made safer by
using thread-local storage.
Expecting a reroll.
cf. <CAHd-oW6A2aBHg80R9kyifvF7thwzam5EYYoN9d2TaBcHJrcKWw@mail.gmail.com>
* ds/commit-graph-bloom-updates (2020-07-01) 10 commits
(merged to 'next' on 2020-07-06 at 177e6b362e)
+ commit-graph: check all leading directories in changed path Bloom filters
+ revision: empty pathspecs should not use Bloom filters
+ revision.c: fix whitespace
+ commit-graph: check chunk sizes after writing
+ commit-graph: simplify chunk writes into loop
+ commit-graph: unify the signatures of all write_graph_chunk_*() functions
+ commit-graph: persist existence of changed-paths
+ bloom: fix logic in get_bloom_filter()
+ commit-graph: change test to die on parse, not load
+ commit-graph: place bloom_settings in context
(this branch uses sg/commit-graph-cleanups.)
Updates to the changed-paths bloom filter.
Will cook in 'next'.
* ss/cmake-build (2020-06-26) 8 commits
- ci: modification of main.yml to use cmake for vs-build job
- cmake: support for building git on windows with msvc and clang.
- cmake: support for building git on windows with mingw
- cmake: support for testing git when building out of the source tree
- cmake: support for testing git with ctest
- cmake: installation support for git
- cmake: generate the shell/perl/python scripts and templates, translations
- Introduce CMake support for configuring Git
CMake support to build with MSVC for Windows bypassing the Makefile.
Waiting for a (hopefully final) review.
* sg/commit-graph-cleanups (2020-06-08) 10 commits
(merged to 'next' on 2020-07-06 at 15c9d77eb9)
+ commit-graph: simplify write_commit_graph_file() #2
+ commit-graph: simplify write_commit_graph_file() #1
+ commit-graph: simplify parse_commit_graph() #2
+ commit-graph: simplify parse_commit_graph() #1
+ commit-graph: clean up #includes
+ diff.h: drop diff_tree_oid() & friends' return value
+ commit-slab: add a function to deep free entries on the slab
+ commit-graph-format.txt: all multi-byte numbers are in network byte order
+ commit-graph: fix parsing the Chunk Lookup table
+ tree-walk.c: don't match submodule entries for 'submod/anything'
(this branch is used by ds/commit-graph-bloom-updates.)
The changed-path Bloom filter is improved using ideas from an
independent implementation.
Will cook in 'next'.
* es/config-hooks (2020-05-21) 4 commits
- hook: add --porcelain to list command
- hook: add list command
- hook: scaffolding for git-hook subcommand
- doc: propose hooks managed by the config
The "hooks defined in config" topic.
What's the status of this one? Abandoned?
* pw/rebase-i-more-options (2020-07-16) 5 commits
- rebase: add --reset-author-date
- rebase -i: support --ignore-date
- sequencer: rename amend_author to author_to_free
- rebase -i: support --committer-date-is-author-date
- rebase -i: add --ignore-whitespace flag
"git rebase -i" learns a bit more options.
Waiting for a (hopefully final) review.
* mt/grep-sparse-checkout (2020-06-12) 6 commits
- config: add setting to ignore sparsity patterns in some cmds
- grep: honor sparse checkout patterns
- config: correctly read worktree configs in submodules
- t/helper/test-config: facilitate addition of new cli options
- t/helper/test-config: return exit codes consistently
- doc: grep: unify info on configuration variables
"git grep" has been tweaked to be limited to the sparse checkout
paths.
Review needed on 4/6; otherwise looking sane.
cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com>
* hn/reftable (2020-07-10) 4 commits
(merged to 'next' on 2020-07-14 at e524883fec)
+ reflog: cleanse messages in the refs.c layer
+ bisect: treat BISECT_HEAD as a pseudo ref
+ t3432: use git-reflog to inspect the reflog for HEAD
+ lib-t6000.sh: write tag using git-update-ref
(this branch is used by hn/reftable-prep-part-2.)
Preliminary clean-up of the refs API in preparation for adding a
new refs backend "reftable".
Will cook in 'next'.
--------------------------------------------------
[Discarded]
* jc/credential-store-file-format-doc (2020-04-27) 1 commit
. credential-store: document the file format a bit more
Now has become a part of Carlo's credential-store fix patches.
* js/ci-skip-on-github-workflow (2020-05-02) 1 commit
. ci: respect the [skip ci] convention in our GitHub workflow "CI/PR"
Allow contributors to mark a branch/push that it does not have to
be built via GitHub actions, in a way similar to how Travis lets
them mark the commits with an embedded "[skip ci]" string.
Superseded by dd/ci-only-on-selective-branches topic.
* dd/ci-only-on-selective-branches (2020-05-05) 2 commits
- CI: limit GitHub Actions to designated branches
- SubmittingPatches: advertise GitHub Actions CI
Instead of always building all branches of all forks of our project
at GitHub via GitHub Actions, only build when branches with known
and specific names are updated, and also a pull request.
Superseded by jk/ci-only-on-selected-branches
* jk/fast-export-anonym (2020-06-22) 4 commits
(merged to 'next' on 2020-06-22 at b517b2f707)
+ fast-export: allow dumping the path mapping
+ fast-export: refactor path printing to not rely on stdout
+ fast-export: anonymize "master" refname
+ fast-export: allow dumping the refname mapping
The way refnames are anonymized has been updated and a way to help
debugging using the anonymized output hsa been added.
Superseded by 'jk/fast-export-anonym-alt'.
* jk/t6000-timestamp-fix (2020-07-07) 1 commit
(merged to 'next' on 2020-07-09 at 633bcd552f)
+ t6000: use test_tick consistently
Test update.
Now it is part of jk/tests-timestamp-fix with a larger scope.
* ds/upgrade-with-existing-extension (2020-07-14) 2 commits
. config: provide extra detail about worktree config
. setup: tweak upgrade policy to grandfather worktreeconfig
(this branch is used by jc/upgrade-v0-fixup.)
In 2.28-rc0, we corrected a bug that some repository extensions are
honored by mistake even in a version 0 repositories (these
configuration variables in extensions.* namespace were supposed to
have special meaning in repositories whose version numbers are 1 or
higher), but this was a bit too big a change.
Superseded by jn/v0-with-extensions-fix
* jc/upgrade-v0-fixup (2020-07-15) 1 commit
. setup: grandfather other extensions that used to be honored by mistake
(this branch uses ds/upgrade-with-existing-extension.)
^ permalink raw reply
* Re: [PATCH v2 00/11] Fix PM hibernation in Xen guests
From: Anchal Agarwal @ 2020-07-16 23:28 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Valentin, Eduardo, len.brown@intel.com, peterz@infradead.org,
benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org,
pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org,
Kamata, Munehisa, mingo@redhat.com,
xen-devel@lists.xenproject.org, Singh, Balbir, axboe@kernel.dk,
konrad.wilk@oracle.com, bp@alien8.de, tglx@linutronix.de,
jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
vkuznets@redhat.com, davem@davemloft.net, Woodhouse, David,
roger.pau@citrix.com
In-Reply-To: <6145a0d9-fd4e-a739-407e-97f7261eecd8@oracle.com>
On Wed, Jul 15, 2020 at 04:49:57PM -0400, Boris Ostrovsky wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 7/15/20 3:49 PM, Anchal Agarwal wrote:
> > On Mon, Jul 13, 2020 at 03:43:33PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >>
> >>
> >>
> >> On 7/10/20 2:17 PM, Agarwal, Anchal wrote:
> >>> Gentle ping on this series.
> >>
> >> Have you tested save/restore?
> >>
> > No, not with the last few series. But a good point, I will test that and get
> > back to you. Do you see anything specific in the series that suggests otherwise?
>
>
> root@ovs104> xl save pvh saved
> Saving to saved new xl format (info 0x3/0x0/1699)
> xc: info: Saving domain 3, type x86 HVM
> xc: Frames: 1044480/1044480 100%
> xc: End of stream: 0/0 0%
> root@ovs104> xl restore saved
> Loading new save file saved (new xl fmt info 0x3/0x0/1699)
> Savefile contains xl domain config in JSON format
> Parsing config from <saved>
> xc: info: Found x86 HVM domain from Xen 4.13
> xc: info: Restoring domain
> xc: info: Restore successful
> xc: info: XenStore: mfn 0xfeffc, dom 0, evt 1
> xc: info: Console: mfn 0xfefff, dom 0, evt 2
> root@ovs104> xl console pvh
> [ 139.943872] ------------[ cut here ]------------
> [ 139.943872] kernel BUG at arch/x86/xen/enlighten.c:205!
> [ 139.943872] invalid opcode: 0000 [#1] SMP PTI
> [ 139.943872] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.8.0-rc5 #26
> [ 139.943872] RIP: 0010:xen_vcpu_setup+0x16d/0x180
> [ 139.943872] Code: 4a 8b 14 f5 40 c9 1b 82 48 89 d8 48 89 2c 02 8b 05
> a4 d4 40 01 85 c0 0f 85 15 ff ff ff 4a 8b 04 f5 40 c9 1b 82 e9 f4 fe ff
> ff <0f> 0b b8 ed ff ff ff e9 14 ff ff ff e8 12 4f 86 00 66 90 66 66 66
> [ 139.943872] RSP: 0018:ffffc9000006bdb0 EFLAGS: 00010046
> [ 139.943872] RAX: 0000000000000000 RBX: ffffc9000014fe00 RCX:
> 0000000000000000
> [ 139.943872] RDX: ffff88803fc00000 RSI: 0000000000016128 RDI:
> 0000000000000000
> [ 139.943872] RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> [ 139.943872] R10: ffffffff826174a0 R11: ffffc9000006bcb4 R12:
> 0000000000016120
> [ 139.943872] R13: 0000000000016120 R14: 0000000000016128 R15:
> 0000000000000000
> [ 139.943872] FS: 0000000000000000(0000) GS:ffff88803fc00000(0000)
> knlGS:0000000000000000
> [ 139.943872] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 139.943872] CR2: 00007f704be8b000 CR3: 000000003901a004 CR4:
> 00000000000606f0
> [ 139.943872] Call Trace:
> [ 139.943872] ? __kmalloc+0x167/0x260
> [ 139.943872] ? xen_manage_runstate_time+0x14a/0x170
> [ 139.943872] xen_vcpu_restore+0x134/0x170
> [ 139.943872] xen_hvm_post_suspend+0x1d/0x30
> [ 139.943872] xen_arch_post_suspend+0x13/0x30
> [ 139.943872] xen_suspend+0x87/0x190
> [ 139.943872] multi_cpu_stop+0x6d/0x110
> [ 139.943872] ? stop_machine_yield+0x10/0x10
> [ 139.943872] cpu_stopper_thread+0x47/0x100
> [ 139.943872] smpboot_thread_fn+0xc5/0x160
> [ 139.943872] ? sort_range+0x20/0x20
> [ 139.943872] kthread+0xfe/0x140
> [ 139.943872] ? kthread_park+0x90/0x90
> [ 139.943872] ret_from_fork+0x22/0x30
> [ 139.943872] Modules linked in:
> [ 139.943872] ---[ end trace 74716859a6b4f0a8 ]---
> [ 139.943872] RIP: 0010:xen_vcpu_setup+0x16d/0x180
> [ 139.943872] Code: 4a 8b 14 f5 40 c9 1b 82 48 89 d8 48 89 2c 02 8b 05
> a4 d4 40 01 85 c0 0f 85 15 ff ff ff 4a 8b 04 f5 40 c9 1b 82 e9 f4 fe ff
> ff <0f> 0b b8 ed ff ff ff e9 14 ff ff ff e8 12 4f 86 00 66 90 66 66 66
> [ 139.943872] RSP: 0018:ffffc9000006bdb0 EFLAGS: 00010046
> [ 139.943872] RAX: 0000000000000000 RBX: ffffc9000014fe00 RCX:
> 0000000000000000
> [ 139.943872] RDX: ffff88803fc00000 RSI: 0000000000016128 RDI:
> 0000000000000000
> [ 139.943872] RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> [ 139.943872] R10: ffffffff826174a0 R11: ffffc9000006bcb4 R12:
> 0000000000016120
> [ 139.943872] R13: 0000000000016120 R14: 0000000000016128 R15:
> 0000000000000000
> [ 139.943872] FS: 0000000000000000(0000) GS:ffff88803fc00000(0000)
> knlGS:0000000000000000
> [ 139.943872] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 139.943872] CR2: 00007f704be8b000 CR3: 000000003901a004 CR4:
> 00000000000606f0
> [ 139.943872] Kernel panic - not syncing: Fatal exception
> [ 139.943872] Shutting down cpus with NMI
> [ 143.927559] Kernel Offset: disabled
> root@ovs104>
>
I think I may have found a bug. There were no issues with V1 version that I
send however, there were issues with V2. I tested both series and found xl
save/restore to be working in V1 but not in V2. I should have tested it.
Anyways, looks the issue is coming from executing syscore ops registered for
hibernation use case during call to xen_suspend.
I remember your comment from earlier where you did ask why we need to
check xen_suspend mode xen_syscore_suspend [patch-004] and I removed that based
on my theoretical understanding of your suggestion that since lock_system_sleep() lock
is taken, we cannot initialize hibernation. I skipped to check the part in the
code where during xen_suspend(), all registered syscore_ops suspend callbacks are
called. Hence the ones registered for PM hibernation will also be called.
With no check there on suspend mode, it fails to return from the function and
they never should be executed in case of xen suspend.
I will revert a part of that check in Patch-004 from V1 and send an updated patch with
the fix.
Thanks,
Anchal
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Nicholas Piggin @ 2020-07-16 23:26 UTC (permalink / raw)
To: peterz
Cc: linux-arch, Arnd Bergmann, x86, linux-kernel, Andy Lutomirski,
linux-mm, Mathieu Desnoyers, Andy Lutomirski, linuxppc-dev
In-Reply-To: <20200716110038.GA119549@hirez.programming.kicks-ass.net>
Excerpts from peterz@infradead.org's message of July 16, 2020 9:00 pm:
> On Thu, Jul 16, 2020 at 08:03:36PM +1000, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 16, 2020 6:50 pm:
>> > On Wed, Jul 15, 2020 at 10:18:20PM -0700, Andy Lutomirski wrote:
>> >> > On Jul 15, 2020, at 9:15 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
>> >> But I’m wondering if all this deferred sync stuff is wrong. In the
>> >> brave new world of io_uring and such, perhaps kernel access matter
>> >> too. Heck, even:
>> >
>> > IIRC the membarrier SYNC_CORE use-case is about user-space
>> > self-modifying code.
>> >
>> > Userspace re-uses a text address and needs to SYNC_CORE before it can be
>> > sure the old text is forgotten. Nothing the kernel does matters there.
>> >
>> > I suppose the manpage could be more clear there.
>>
>> True, but memory ordering of kernel stores from kernel threads for
>> regular mem barrier is the concern here.
>>
>> Does io_uring update completion queue from kernel thread or interrupt,
>> for example? If it does, then membarrier will not order such stores
>> with user memory accesses.
>
> So we're talking about regular membarrier() then? Not the SYNC_CORE
> variant per-se.
Well, both but Andy in this case was wondering about kernel writes
vs user.
>
> Even there, I'll argue we don't care, but perhaps Mathieu has a
> different opinion. All we care about is that all other threads (or CPUs
> for GLOBAL) observe an smp_mb() before it returns.
>
> Any serialization against whatever those other threads/CPUs are running
> at the instant of the syscall is external to the syscall, we make no
> gauarantees about that. That is, we can fundamentally not say what
> another CPU is executing concurrently. Nor should we want to.
>
> So if you feel that your membarrier() ought to serialize against remote
> execution, you need to arrange a quiecent state on the remote side
> yourself.
>
> Now, normally membarrier() is used to implement userspace RCU like
> things, and there all that matters is that the remote CPUs observe the
> beginngin of the new grace-period, ie counter flip, and we observe their
> read-side critical sections, or smething like that, it's been a while
> since I looked at all that.
>
> It's always been the case that concurrent syscalls could change user
> memory, io_uring doesn't change that, it just makes it even less well
> defined when that would happen. If you want to serialize against that,
> you need to arrange that externally.
membarrier does replace barrier instructions on remote CPUs, which do
order accesses performed by the kernel on the user address space. So
membarrier should too I guess.
Normal process context accesses like read(2) will do so because they
don't get filtered out from IPIs, but kernel threads using the mm may
not.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v3 07/21] ASoC: atmel: merge .digital_mute() into .mute_stream()
From: Kuninori Morimoto @ 2020-07-16 23:27 UTC (permalink / raw)
To: Mark Brown; +Cc: Linux-ALSA
In-Reply-To: <20200716204403.GA10651@sirena.org.uk>
Hi Mark
> > snd_soc_dai_digital_mute() is internally using both
> > mute_stream() (1) or digital_mute() (2), but the difference between
> > these 2 are only handling direction.
>
> At least this patch needs a rebase against current code, possibly others.
I noticed it yesterday.
OK, I will rebase and re-post v4
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 00/11] Fix PM hibernation in Xen guests
From: Anchal Agarwal @ 2020-07-16 23:28 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
x86@kernel.org, jgross@suse.com, linux-pm@vger.kernel.org,
linux-mm@kvack.org, Kamata, Munehisa, sstabellini@kernel.org,
konrad.wilk@oracle.com, roger.pau@citrix.com, axboe@kernel.dk,
davem@davemloft.net, rjw@rjwysocki.net, len.brown@intel.com,
pavel@ucw.cz, peterz@infradead.org, Valentin, Eduardo,
Singh, Balbir, xen-devel@lists.xenproject.org,
vkuznets@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Woodhouse, David,
benh@kernel.crashing.org
In-Reply-To: <6145a0d9-fd4e-a739-407e-97f7261eecd8@oracle.com>
On Wed, Jul 15, 2020 at 04:49:57PM -0400, Boris Ostrovsky wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 7/15/20 3:49 PM, Anchal Agarwal wrote:
> > On Mon, Jul 13, 2020 at 03:43:33PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >>
> >>
> >>
> >> On 7/10/20 2:17 PM, Agarwal, Anchal wrote:
> >>> Gentle ping on this series.
> >>
> >> Have you tested save/restore?
> >>
> > No, not with the last few series. But a good point, I will test that and get
> > back to you. Do you see anything specific in the series that suggests otherwise?
>
>
> root@ovs104> xl save pvh saved
> Saving to saved new xl format (info 0x3/0x0/1699)
> xc: info: Saving domain 3, type x86 HVM
> xc: Frames: 1044480/1044480 100%
> xc: End of stream: 0/0 0%
> root@ovs104> xl restore saved
> Loading new save file saved (new xl fmt info 0x3/0x0/1699)
> Savefile contains xl domain config in JSON format
> Parsing config from <saved>
> xc: info: Found x86 HVM domain from Xen 4.13
> xc: info: Restoring domain
> xc: info: Restore successful
> xc: info: XenStore: mfn 0xfeffc, dom 0, evt 1
> xc: info: Console: mfn 0xfefff, dom 0, evt 2
> root@ovs104> xl console pvh
> [ 139.943872] ------------[ cut here ]------------
> [ 139.943872] kernel BUG at arch/x86/xen/enlighten.c:205!
> [ 139.943872] invalid opcode: 0000 [#1] SMP PTI
> [ 139.943872] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.8.0-rc5 #26
> [ 139.943872] RIP: 0010:xen_vcpu_setup+0x16d/0x180
> [ 139.943872] Code: 4a 8b 14 f5 40 c9 1b 82 48 89 d8 48 89 2c 02 8b 05
> a4 d4 40 01 85 c0 0f 85 15 ff ff ff 4a 8b 04 f5 40 c9 1b 82 e9 f4 fe ff
> ff <0f> 0b b8 ed ff ff ff e9 14 ff ff ff e8 12 4f 86 00 66 90 66 66 66
> [ 139.943872] RSP: 0018:ffffc9000006bdb0 EFLAGS: 00010046
> [ 139.943872] RAX: 0000000000000000 RBX: ffffc9000014fe00 RCX:
> 0000000000000000
> [ 139.943872] RDX: ffff88803fc00000 RSI: 0000000000016128 RDI:
> 0000000000000000
> [ 139.943872] RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> [ 139.943872] R10: ffffffff826174a0 R11: ffffc9000006bcb4 R12:
> 0000000000016120
> [ 139.943872] R13: 0000000000016120 R14: 0000000000016128 R15:
> 0000000000000000
> [ 139.943872] FS: 0000000000000000(0000) GS:ffff88803fc00000(0000)
> knlGS:0000000000000000
> [ 139.943872] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 139.943872] CR2: 00007f704be8b000 CR3: 000000003901a004 CR4:
> 00000000000606f0
> [ 139.943872] Call Trace:
> [ 139.943872] ? __kmalloc+0x167/0x260
> [ 139.943872] ? xen_manage_runstate_time+0x14a/0x170
> [ 139.943872] xen_vcpu_restore+0x134/0x170
> [ 139.943872] xen_hvm_post_suspend+0x1d/0x30
> [ 139.943872] xen_arch_post_suspend+0x13/0x30
> [ 139.943872] xen_suspend+0x87/0x190
> [ 139.943872] multi_cpu_stop+0x6d/0x110
> [ 139.943872] ? stop_machine_yield+0x10/0x10
> [ 139.943872] cpu_stopper_thread+0x47/0x100
> [ 139.943872] smpboot_thread_fn+0xc5/0x160
> [ 139.943872] ? sort_range+0x20/0x20
> [ 139.943872] kthread+0xfe/0x140
> [ 139.943872] ? kthread_park+0x90/0x90
> [ 139.943872] ret_from_fork+0x22/0x30
> [ 139.943872] Modules linked in:
> [ 139.943872] ---[ end trace 74716859a6b4f0a8 ]---
> [ 139.943872] RIP: 0010:xen_vcpu_setup+0x16d/0x180
> [ 139.943872] Code: 4a 8b 14 f5 40 c9 1b 82 48 89 d8 48 89 2c 02 8b 05
> a4 d4 40 01 85 c0 0f 85 15 ff ff ff 4a 8b 04 f5 40 c9 1b 82 e9 f4 fe ff
> ff <0f> 0b b8 ed ff ff ff e9 14 ff ff ff e8 12 4f 86 00 66 90 66 66 66
> [ 139.943872] RSP: 0018:ffffc9000006bdb0 EFLAGS: 00010046
> [ 139.943872] RAX: 0000000000000000 RBX: ffffc9000014fe00 RCX:
> 0000000000000000
> [ 139.943872] RDX: ffff88803fc00000 RSI: 0000000000016128 RDI:
> 0000000000000000
> [ 139.943872] RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> [ 139.943872] R10: ffffffff826174a0 R11: ffffc9000006bcb4 R12:
> 0000000000016120
> [ 139.943872] R13: 0000000000016120 R14: 0000000000016128 R15:
> 0000000000000000
> [ 139.943872] FS: 0000000000000000(0000) GS:ffff88803fc00000(0000)
> knlGS:0000000000000000
> [ 139.943872] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 139.943872] CR2: 00007f704be8b000 CR3: 000000003901a004 CR4:
> 00000000000606f0
> [ 139.943872] Kernel panic - not syncing: Fatal exception
> [ 139.943872] Shutting down cpus with NMI
> [ 143.927559] Kernel Offset: disabled
> root@ovs104>
>
I think I may have found a bug. There were no issues with V1 version that I
send however, there were issues with V2. I tested both series and found xl
save/restore to be working in V1 but not in V2. I should have tested it.
Anyways, looks the issue is coming from executing syscore ops registered for
hibernation use case during call to xen_suspend.
I remember your comment from earlier where you did ask why we need to
check xen_suspend mode xen_syscore_suspend [patch-004] and I removed that based
on my theoretical understanding of your suggestion that since lock_system_sleep() lock
is taken, we cannot initialize hibernation. I skipped to check the part in the
code where during xen_suspend(), all registered syscore_ops suspend callbacks are
called. Hence the ones registered for PM hibernation will also be called.
With no check there on suspend mode, it fails to return from the function and
they never should be executed in case of xen suspend.
I will revert a part of that check in Patch-004 from V1 and send an updated patch with
the fix.
Thanks,
Anchal
^ permalink raw reply
* uboot-test-hooks: dfu-util
From: Stephen Warren @ 2020-07-16 23:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fadb3fa2-82eb-0cab-f91d-fb7a5720e026@gmx.de>
On 7/15/20 12:14 PM, Heinrich Schuchardt wrote:
> On 15.07.20 19:38, Heinrich Schuchardt wrote:
>> On 15.07.20 17:57, Stephen Warren wrote:
>>> On 7/15/20 4:34 AM, Heinrich Schuchardt wrote:
>>>> Hello Stephen,
>>>>
>>>> I have just looked into dfu testing.
>>>>
>>>> Do we still need a custom dfu-util? At least the dfu-util provided by
>>>> Ubuntu bionic/universe in our Docker image provides the -p parameter.
>>>
>>> Yes, it looks like the -p option is supported by the dfu-util in Xenial
>>> too (I need to run Xenial due to other dependencies...)
>>>
>>> However, this binary has one more patch in it which I need locally at least:
>>>> https://github.com/swarren/dfu-util/commit/23561bd0ca4f5f62488451826d4a03683ad70e8a
>
> You are not alone with your problem:
>
> https://github.com/motive-ai/dfu-util/commit/c7e3c3c0cae977b6c4638b3af44968f50ec1447a
>
> I saw this explanation in
> https://github.com/zephyrproject-rtos/zephyr/issues/8734:
>
> "As I explained in the pull request, the problem is not that the timeout
> in dfu-util is too small (the device should always respond immediately
> to the DFU request USB transaction) but that the device is not correctly
> implementing the DFU standard and the bwPollTimeout in the DFU_GETSTATUS
> response." Cf.
> https://github.com/zephyrproject-rtos/zephyr/pull/15330/commits
>
> Could it be that we have a similar problem with our U-Boot
> implementation (drivers/usb/gadget/f_dfu.c)?
>
> The value of DFU_MANIFEST_POLL_TIMEOUT and DFU_MANIFEST_POLL_TIMEOUT
> varies a lot between the boards:
>
> include/dfu.h:111:
> #ifndef DFU_MANIFEST_POLL_TIMEOUT
> #define DFU_MANIFEST_POLL_TIMEOUT DFU_DEFAULT_POLL_TIMEOUT
> #endif
>
> include/configs/odroid_xu3.h
> #define DFU_DEFAULT_POLL_TIMEOUT 300
>
> include/configs/corvus.h
> #define DFU_MANIFEST_POLL_TIMEOUT 25000
>
> Does increasing this value in include/configs/jetson-tk1.h help with
> your Jetson TK1 board?
I took a look at this and discovered a few things!
1) I can't repro the original timeout issuing I was having, with any of
v2016.03, v2016.05, or v2016.07 (i.e. the current upstream versions
around when I first checked in the custom dfu-util with the timeout
patch). The commit comments indicate it may have been an issue with one
of our downstream branches at the time. So, I removed that change and
re-ran testing on all the branches that I *currently* test (upstream and
downstream) and didn't see any issue. Hopefully it won't show up
intermittently.
2) Even though Ubuntu 16.04's dfu-util binary indicates that it supports
the -p command-line option, its implementation is missing since the
required library wasn't present when Ubuntu built the package. Trying to
use the -p feature simply results in dfu-util printing an error message.
So, I personally will still need to use a custom binary of dfu-util
because of this, but perhaps people on newer OSs won't. I've moved this
dfu-util binary into a different git repo so only I'll end up using it.
So, in summary it doesn't look like there is an issue in the current
U-Boot DFU code, or at least not one I can detect.
^ permalink raw reply
* + memcg-oom-check-memcg-margin-for-parallel-oom.patch added to -mm tree
From: Andrew Morton @ 2020-07-16 23:28 UTC (permalink / raw)
To: chris, hannes, laoar.shao, mhocko, mhocko, mm-commits,
penguin-kernel, rientjes
In-Reply-To: <20200703151445.b6a0cfee402c7c5c4651f1b1@linux-foundation.org>
The patch titled
Subject: memcg, oom: check memcg margin for parallel oom
has been added to the -mm tree. Its filename is
memcg-oom-check-memcg-margin-for-parallel-oom.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/memcg-oom-check-memcg-margin-for-parallel-oom.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/memcg-oom-check-memcg-margin-for-parallel-oom.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Yafang Shao <laoar.shao@gmail.com>
Subject: memcg, oom: check memcg margin for parallel oom
Memcg oom killer invocation is synchronized by the global oom_lock and
tasks are sleeping on the lock while somebody is selecting the victim or
potentially race with the oom_reaper is releasing the victim's memory.
This can result in a pointless oom killer invocation because a waiter
might be racing with the oom_reaper
P1 oom_reaper P2
oom_reap_task mutex_lock(oom_lock)
out_of_memory # no victim because we have one already
__oom_reap_task_mm mute_unlock(oom_lock)
mutex_lock(oom_lock)
set MMF_OOM_SKIP
select_bad_process
# finds a new victim
The page allocator prevents from this race by trying to allocate after the
lock can be acquired (in __alloc_pages_may_oom) which acts as a last
minute check. Moreover page allocator simply doesn't block on the
oom_lock and simply retries the whole reclaim process.
Memcg oom killer should do the last minute check as well. Call
mem_cgroup_margin to do that. Trylock on the oom_lock could be done as
well but this doesn't seem to be necessary at this stage.
[mhocko@kernel.org: commit log]
Link: http://lkml.kernel.org/r/1594735034-19190-1-git-send-email-laoar.shao@gmail.com
Suggested-by: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Chris Down <chris@chrisdown.name>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/mm/memcontrol.c~memcg-oom-check-memcg-margin-for-parallel-oom
+++ a/mm/memcontrol.c
@@ -1665,15 +1665,21 @@ static bool mem_cgroup_out_of_memory(str
.gfp_mask = gfp_mask,
.order = order,
};
- bool ret;
+ bool ret = true;
if (mutex_lock_killable(&oom_lock))
return true;
+
+ if (mem_cgroup_margin(memcg) >= (1 << order))
+ goto unlock;
+
/*
* A few threads which were not waiting at mutex_lock_killable() can
* fail to bail out. Therefore, check again after holding oom_lock.
*/
ret = should_force_charge() || out_of_memory(&oc);
+
+unlock:
mutex_unlock(&oom_lock);
return ret;
}
_
Patches currently in -mm which might be from laoar.shao@gmail.com are
mm-memcg-avoid-stale-protection-values-when-cgroup-is-above-protection.patch
memcg-oom-check-memcg-margin-for-parallel-oom.patch
mm-oom-make-the-calculation-of-oom-badness-more-accurate.patch
mm-oom-make-the-calculation-of-oom-badness-more-accurate-v3.patch
^ 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.