* [PATCH v5 net-next 1/6] net: ethernet: ti: cpsw: use cpdma channels in backward order for txq
From: Ivan Khoronzhuk @ 2018-07-23 21:26 UTC (permalink / raw)
To: davem, grygorii.strashko
Cc: corbet, akpm, netdev, linux-doc, linux-kernel, linux-omap,
vinicius.gomes, henrik, jesus.sanchez-palencia, ilias.apalodimas,
p-varis, spatton, francois.ozog, yogeshs, nsekhar, andrew,
Ivan Khoronzhuk
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
The cpdma channel highest priority is from hi to lo number.
The driver has limited number of descriptors that are shared between
number of cpdma channels. Number of queues can be tuned with ethtool,
that allows to not spend descriptors on not needed cpdma channels.
In AVB usually only 2 tx queues can be enough with rate limitation.
The rate limitation can be used only for hi priority queues. Thus, to
use only 2 queues the 8 has to be created. It's wasteful.
So, in order to allow using only needed number of rate limited
tx queues, save resources, and be able to set rate limitation for
them, let assign tx cpdma channels in backward order to queues.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 00761fe59848..4425b537b9dd 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -968,8 +968,8 @@ static int cpsw_tx_mq_poll(struct napi_struct *napi_tx, int budget)
/* process every unprocessed channel */
ch_map = cpdma_ctrl_txchs_state(cpsw->dma);
- for (ch = 0, num_tx = 0; ch_map; ch_map >>= 1, ch++) {
- if (!(ch_map & 0x01))
+ for (ch = 0, num_tx = 0; ch_map & 0xff; ch_map <<= 1, ch++) {
+ if (!(ch_map & 0x80))
continue;
txv = &cpsw->txv[ch];
@@ -2432,7 +2432,7 @@ static int cpsw_update_channels_res(struct cpsw_priv *priv, int ch_num, int rx)
void (*handler)(void *, int, int);
struct netdev_queue *queue;
struct cpsw_vector *vec;
- int ret, *ch;
+ int ret, *ch, vch;
if (rx) {
ch = &cpsw->rx_ch_num;
@@ -2445,7 +2445,8 @@ static int cpsw_update_channels_res(struct cpsw_priv *priv, int ch_num, int rx)
}
while (*ch < ch_num) {
- vec[*ch].ch = cpdma_chan_create(cpsw->dma, *ch, handler, rx);
+ vch = rx ? *ch : 7 - *ch;
+ vec[*ch].ch = cpdma_chan_create(cpsw->dma, vch, handler, rx);
queue = netdev_get_tx_queue(priv->ndev, *ch);
queue->tx_maxrate = 0;
@@ -2982,7 +2983,7 @@ static int cpsw_probe(struct platform_device *pdev)
u32 slave_offset, sliver_offset, slave_size;
const struct soc_device_attribute *soc;
struct cpsw_common *cpsw;
- int ret = 0, i;
+ int ret = 0, i, ch;
int irq;
cpsw = devm_kzalloc(&pdev->dev, sizeof(struct cpsw_common), GFP_KERNEL);
@@ -3157,7 +3158,8 @@ static int cpsw_probe(struct platform_device *pdev)
if (soc)
cpsw->quirk_irq = 1;
- cpsw->txv[0].ch = cpdma_chan_create(cpsw->dma, 0, cpsw_tx_handler, 0);
+ ch = cpsw->quirk_irq ? 0 : 7;
+ cpsw->txv[0].ch = cpdma_chan_create(cpsw->dma, ch, cpsw_tx_handler, 0);
if (IS_ERR(cpsw->txv[0].ch)) {
dev_err(priv->dev, "error initializing tx dma channel\n");
ret = PTR_ERR(cpsw->txv[0].ch);
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH] checkpatch: Discourage use with --f/--file outside of drivers/staging ?
From: Joe Perches @ 2018-07-23 21:28 UTC (permalink / raw)
To: LKML
Perhaps some patch like this could help reduce the
number of ill-considered checkpatch submissions
for files outside of drivers/staging/
Concept and message wordsmithing appreciated...
---
scripts/checkpatch.pl | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 34e4683de7a3..1a93421d5b1d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2483,6 +2483,10 @@ sub process {
WARN("OBSOLETE",
"$realfile is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please.\n");
}
+ if ($file && $filename !~ m@^drivers/staging/@) {
+ WARN("CHECKPATCH_FILE",
+ "Using -f/--file with '$realfile' may not be appropriate.\n");
+ }
if ($realfile =~ m@^(?:drivers/net/|net/|drivers/staging/)@) {
$check = 1;
} else {
^ permalink raw reply related
* Re: [PATCH v6 8/8] fetch-pack: implement ref-in-want
From: Jonathan Nieder @ 2018-07-23 21:28 UTC (permalink / raw)
To: Duy Nguyen
Cc: Brandon Williams, Git Mailing List, Jonathan Tan, Junio C Hamano,
Stefan Beller
In-Reply-To: <CACsJy8COu2zmWWuodww=ZdURZBw6CVx9ibbfeAJ0Q4pQ-ng_uA@mail.gmail.com>
Hi,
Duy Nguyen wrote:
> On Mon, Jul 23, 2018 at 7:53 PM Brandon Williams <bmwill@google.com> wrote:
>> What criteria is used to determine if something should be translated?
[...]
> Besides drawing the line "benefit from (not) being translated" varies
> from one developer to another. I think it's just easier and more
> consistent to stick to "if it's not machine-readable (or really meant
> for devs, like BUG()), translate it" and leave it to translators to
> decide.
Yup, this is my understanding too: everything user-facing (as opposed
to machine-facing) that isn't a "this can't happen" local assertion
error (BUG) should be translated.
Protocol and format errors aren't BUG (assertion error) because they
reflect something that shouldn't be possible to happen due to someone
*else* behaving badly. BUG is for errors that shouldn't be possible
due to the version of Git that produces the message behaving badly.
po/README says
- Don't mark everything for translation, only strings which will be
read by humans (the porcelain interface) should be translated.
The output from Git's plumbing utilities will primarily be read by
programs and would break scripts under non-C locales if it was
translated. Plumbing strings should not be translated, since
they're part of Git's API.
I kind of wish we had a rule that was less fuzzy, since then we could
enforce it. For example, JGit has a rule that *all* strings should be
translatable unless they have a comment explaining why they shouldn't
be (which goes a little too far --- there are those comments all over
the place).
Thanks,
Jonathan
^ permalink raw reply
* Linux RT 4.14 Merge conflict
From: Dan Murphy @ 2018-07-23 20:25 UTC (permalink / raw)
To: linux-rt-users@vger.kernel.org, Steven Rostedt
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
Hello!
There is a merge conflict when merging in the latest 4.14 stable release into the current 4.14 rt stable release.
Attached is the merge conflict that is seen.
We appreciate it if the merge conflict resolution can come from the RT stable branch.
Dan
--
------------------
Dan Murphy
[-- Attachment #2: linux_41457_rt_merge_conflict.txt --]
[-- Type: text/plain, Size: 3173 bytes --]
diff --cc kernel/sched/core.c
index d6c2afc8c629,31615d1ae44c..000000000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -1016,16 -978,8 +1043,12 @@@ struct migration_arg
static struct rq *__migrate_task(struct rq *rq, struct rq_flags *rf,
struct task_struct *p, int dest_cpu)
{
- if (p->flags & PF_KTHREAD) {
- if (unlikely(!cpu_online(dest_cpu)))
- return rq;
- } else {
- if (unlikely(!cpu_active(dest_cpu)))
- return rq;
- }
-
/* Affinity changed (again). */
++<<<<<<< HEAD
+ if (!cpumask_test_cpu(dest_cpu, p->cpus_ptr))
++=======
+ if (!is_cpu_allowed(p, dest_cpu))
++>>>>>>> 5553933d40157e41ed2ed6390e2ebff4f548f96e
return rq;
update_rq_clock(rq);
@@@ -1595,11 -1507,10 +1618,17 @@@ static int select_fallback_rq(int cpu,
for (;;) {
/* Any allowed, online CPU? */
++<<<<<<< HEAD
+ for_each_cpu(dest_cpu, p->cpus_ptr) {
+ if (!(p->flags & PF_KTHREAD) && !cpu_active(dest_cpu))
+ continue;
+ if (!cpu_online(dest_cpu))
++=======
+ for_each_cpu(dest_cpu, &p->cpus_allowed) {
+ if (!is_cpu_allowed(p, dest_cpu))
++>>>>>>> 5553933d40157e41ed2ed6390e2ebff4f548f96e
continue;
+
goto out;
}
@@@ -1662,8 -1573,7 +1691,12 @@@ int select_task_rq(struct task_struct *
* [ this allows ->select_task() to simply return task_cpu(p) and
* not worry about this generic constraint ]
*/
++<<<<<<< HEAD
+ if (unlikely(!cpumask_test_cpu(cpu, p->cpus_ptr) ||
+ !cpu_online(cpu)))
++=======
+ if (unlikely(!is_cpu_allowed(p, cpu)))
++>>>>>>> 5553933d40157e41ed2ed6390e2ebff4f548f96e
cpu = select_fallback_rq(task_cpu(p), p);
return cpu;
diff --cc kernel/trace/trace.c
index d67ac5c2bc66,e268750bd4ad..000000000000
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@@ -3389,17 -3374,15 +3389,23 @@@ static void print_func_help_header_irq(
tgid ? tgid_space : space);
seq_printf(m, "# %s / _----=> need-resched\n",
tgid ? tgid_space : space);
- seq_printf(m, "# %s| / _---=> hardirq/softirq\n",
+ seq_printf(m, "# %s| / _----=> need-resched_lazy\n",
+ tgid ? tgid_space : space);
+ seq_printf(m, "# %s|| / _---=> hardirq/softirq\n",
tgid ? tgid_space : space);
- seq_printf(m, "# %s|| / _--=> preempt-depth\n",
+ seq_printf(m, "# %s||| / _--=> preempt-depth\n",
tgid ? tgid_space : space);
- seq_printf(m, "# %s||| / delay\n",
+ seq_printf(m, "# %s|||| / delay\n",
tgid ? tgid_space : space);
++<<<<<<< HEAD
+ seq_printf(m, "# TASK-PID CPU#%s||||| TIMESTAMP FUNCTION\n",
+ tgid ? " TGID " : space);
+ seq_printf(m, "# | | | %s||||| | |\n",
++=======
+ seq_printf(m, "# TASK-PID %sCPU# |||| TIMESTAMP FUNCTION\n",
+ tgid ? " TGID " : space);
+ seq_printf(m, "# | | %s | |||| | |\n",
++>>>>>>> 5553933d40157e41ed2ed6390e2ebff4f548f96e
tgid ? " | " : space);
}
^ permalink raw reply
* Re: [patch v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy
From: Roman Gushchin @ 2018-07-23 21:28 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Michal Hocko, Vladimir Davydov, Johannes Weiner,
Tejun Heo, cgroups, linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.21.1807231331510.105582@chino.kir.corp.google.com>
On Mon, Jul 23, 2018 at 01:33:19PM -0700, David Rientjes wrote:
> On Mon, 16 Jul 2018, David Rientjes wrote:
>
> > > And "tree" is different. It actually changes how the selection algorithm works,
> > > and sub-tree settings do matter in this case.
> > >
> >
> > "Tree" is considering the entity as a single indivisible memory consumer,
> > it is compared with siblings based on its hierarhical usage. It has
> > cgroup oom policy.
> >
> > It would be possible to separate this out, if you'd prefer, to account
> > an intermediate cgroup as the largest descendant or the sum of all
> > descendants. I hadn't found a usecase for that, however, but it doesn't
> > mean there isn't one. If you'd like, I can introduce another tunable.
> >
>
> Roman, I'm trying to make progress so that the cgroup aware oom killer is
> in a state that it can be merged. Would you prefer a second tunable here
> to specify a cgroup's points includes memory from its subtree?
Hi, David!
It's hard to tell, because I don't have a clear picture of what you're
suggesting now. My biggest concern about your last version was that it's hard
to tell what oom_policy really defines. Each value has it's own application
rules, which is a bit messy (some values are meaningful for OOMing cgroup only,
other are reading on hierarchy traversal).
If you know how to make it clear and non-contradictory,
please, describe the proposed interface.
>
> It would be helpful if you would also review the rest of the patchset.
I think, that we should focus on interface semantics right now.
If we can't agree on how the things should work, it makes no sense
to discuss the implementation.
Thanks!
^ permalink raw reply
* Re: [PATCH] fetch-pack: mark die strings for translation
From: Jonathan Nieder @ 2018-07-23 21:29 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <20180723175635.31323-1-bmwill@google.com>
Brandon Williams wrote:
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> fetch-pack.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
^ permalink raw reply
* Re: [patch v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy
From: Roman Gushchin @ 2018-07-23 21:28 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Michal Hocko, Vladimir Davydov, Johannes Weiner,
Tejun Heo, cgroups, linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.21.1807231331510.105582@chino.kir.corp.google.com>
On Mon, Jul 23, 2018 at 01:33:19PM -0700, David Rientjes wrote:
> On Mon, 16 Jul 2018, David Rientjes wrote:
>
> > > And "tree" is different. It actually changes how the selection algorithm works,
> > > and sub-tree settings do matter in this case.
> > >
> >
> > "Tree" is considering the entity as a single indivisible memory consumer,
> > it is compared with siblings based on its hierarhical usage. It has
> > cgroup oom policy.
> >
> > It would be possible to separate this out, if you'd prefer, to account
> > an intermediate cgroup as the largest descendant or the sum of all
> > descendants. I hadn't found a usecase for that, however, but it doesn't
> > mean there isn't one. If you'd like, I can introduce another tunable.
> >
>
> Roman, I'm trying to make progress so that the cgroup aware oom killer is
> in a state that it can be merged. Would you prefer a second tunable here
> to specify a cgroup's points includes memory from its subtree?
Hi, David!
It's hard to tell, because I don't have a clear picture of what you're
suggesting now. My biggest concern about your last version was that it's hard
to tell what oom_policy really defines. Each value has it's own application
rules, which is a bit messy (some values are meaningful for OOMing cgroup only,
other are reading on hierarchy traversal).
If you know how to make it clear and non-contradictory,
please, describe the proposed interface.
>
> It would be helpful if you would also review the rest of the patchset.
I think, that we should focus on interface semantics right now.
If we can't agree on how the things should work, it makes no sense
to discuss the implementation.
Thanks!
^ permalink raw reply
* [PATCH 00/12] i2c: quirks: add zero length checks and update drivers
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, linux-arm-kernel, linux-arm-msm,
linux-kernel, linux-omap, linux-soc, linux-tegra
I had this idea for quite some time on my todo list but a soon to be
implemented refactoring in the i2c-rcar driver now finally made me do it. Add a
'can't do 0 length messages' quirk to the quirk infrastructure for and remove
the manual handling from the drivers. This makes the quirk much more visible.
(Quite some prominent vendors in that list) We also have a centralized place to
handle updates to the quirk detection if that is ever needed.
I have tested this with the i2c-rcar and i2c-sh_mobile driver on a Renesas
SalvatorXS board equipped with M3-N (r8a77965).
A git branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirk-no-zero-len
Looking forward to comments, reviews, tests...
Thanks,
Wolfram
Wolfram Sang (12):
i2c: quirks: add zero length checks
i2c: designware-master: use core to detect 'no zero length' quirk
i2c: mxs: use core to detect 'no zero length' quirk
i2c: omap: use core to detect 'no zero length' quirk
i2c: pmcmsp: use core to detect 'no zero length' quirk
i2c: qup: use core to detect 'no zero length' quirk
i2c: stu300: use core to detect 'no zero length' quirk
i2c: tegra: use core to detect 'no zero length' quirk
i2c: zx2967: use core to detect 'no zero length' quirk
i2c: rcar: use core to detect 'no zero length' quirk
i2c: xlr: use core to detect 'no zero length' quirk
i2c: sh_mobile: use core to detect 'no zero length read' quirk
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
drivers/i2c/busses/i2c-tegra.c | 4 +---
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
13 files changed, 60 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 09/12] i2c: zx2967: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Jun Nie, Baoyou Xie, Shawn Guo,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index 48281c1b30c6..b8f9e020d80e 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -281,9 +281,6 @@ static int zx2967_i2c_xfer_msg(struct zx2967_i2c *i2c,
int ret;
int i;
- if (msg->len == 0)
- return -EINVAL;
-
zx2967_i2c_flush_fifos(i2c);
i2c->cur_trans = msg->buf;
@@ -498,6 +495,10 @@ static const struct i2c_algorithm zx2967_i2c_algo = {
.functionality = zx2967_i2c_func,
};
+static const struct i2c_adapter_quirks zx2967_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id zx2967_i2c_of_match[] = {
{ .compatible = "zte,zx296718-i2c", },
{ },
@@ -568,6 +569,7 @@ static int zx2967_i2c_probe(struct platform_device *pdev)
strlcpy(i2c->adap.name, "zx2967 i2c adapter",
sizeof(i2c->adap.name));
i2c->adap.algo = &zx2967_i2c_algo;
+ i2c->adap.quirks = &zx2967_i2c_quirks;
i2c->adap.nr = pdev->id;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas
From: Jeff King @ 2018-07-23 21:30 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List, Elijah Newren
In-Reply-To: <CACsJy8Cex0Uby-eBRBqc_ScZd=EnCV6e0ZuaZEmopGkrvhrBzQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 08:49:59PM +0200, Duy Nguyen wrote:
> On Mon, Jul 23, 2018 at 8:38 PM Duy Nguyen <pclouds@gmail.com> wrote:
> > I will have to study the thread dispatch code more to have a better
> > answer, unfortunately.
>
> Well.. I thought I would need this weekend for this, but a quick look
> and ll_find_deltas() suggests that what we're doing is safe. At least
> you and Jeff are way to familiar with the delta window concept in
> pack-objects. So in multithread mode, we have a big list of all
> objects, then the list is cut in N sublists and each is owned entirely
> by one thread. Each thread then can slide a window over this sublist
> to search for the best delta.
>
> Because of this partitioning, if trg_entry is being processed now, it
> will not be accessed by any other thread. It's owned by this thread
> and will be accessed again as src_entry when the next entry becomes
> the delta target in the same thread. As long as we don't access
> objects of another thread (and my v1 violates this) we should be ok.
Yes, that matches my knowledge of how this all works. And if it didn't,
I think the code would have been racy even _before_ your patches.
The only thing that this pack->delta_size approach is changing is that
managing that array needs to happen under lock, because it touches the
whole list.
And as long as we back-fill it from any arbitrary e->delta_size_, that
means that touching e->delta_size_ needs to be done under lock. That's
why I think keeping the individual valid flag in each entry makes the
most sense. Then whenever we overflow a particular e->delta_size_, we
don't have to care about anybody else's size.
Which I think is what your v2 patch is doing.
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] t7406: avoid failures solely due to timing issues
From: Junio C Hamano @ 2018-07-23 21:31 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitgitgadget, git, Johannes Schindelin
In-Reply-To: <CAGZ79kag=YC6PxOnBbVAqY92dNd5yuqfvash-oPVrEktowNbVA@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> This test was last touched in c66410ed32a (submodule init:
> redirect stdout to stderr, 2016-05-02), merged as f2c96ceb57a
> (Merge branch 'sb/submodule-init', 2016-05-17)
>
> The parallelizing effort was made before that
> (2335b870fa7 (submodule update: expose parallelism to the
> user, 2016-02-29) via bdebbeb3346 (Merge branch
> 'sb/submodule-parallel-update', 2016-04-06)), but did not
> review existing tests for the newly introduced raciness.
Ah, that explains what I was scratching my head about. I somehow
thought that the parallel update broke an otherwise working test
written back in the serial days, but it seems it was the other way
around. The test was simply careless.
Nice to have the two-year old issue fixed. Thanks, all.
^ permalink raw reply
* [U-Boot] [PATCH] fs: ext4: Prevent erasing buffer past file size
From: Marek Vasut @ 2018-07-23 21:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180723140900.GG11755@bill-the-cat>
On 07/23/2018 04:09 PM, Tom Rini wrote:
> On Mon, Jul 23, 2018 at 11:42:12AM +0200, Marek Vasut wrote:
>
>> The variable 'n' represents the number of bytes to be read from a certain
>> offset in a file, to a certain offset in buffer 'buf'. The variable 'len'
>> represents the length of the entire file, clamped correctly to avoid any
>> overflows.
>>
>> Therefore, comparing 'n' and 'len' to determine whether clearing 'n'
>> bytes of the buffer 'buf' at a certain offset would clear data past
>> buffer 'buf' cannot lead to a correct result, since the 'n' does not
>> contain the offset from the beginning of the file.
>>
>> This patch keeps track of the amount of data read and checks for the
>> buffer overflow by comparing the 'n' to the remaining amount of data
>> to be read instead.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Ian Ray <ian.ray@ge.com>
>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
>> Cc: Stefano Babic <sbabic@denx.de>
>> Cc: Tom Rini <trini@konsulko.com>
>> Fixes: ecdfb4195b20 ("ext4: recover from filesystem corruption when reading")
>
> Good catch. Can this problem also be recreated/tested with
> test/fs/fs-test.sh? Thanks!
>
I think so. I'd memalign() a buffer with some safe space around it, ie.
a 4k page on each side and poison it with a pattern. I'd then read a
file which is not ext4 FS block size aligned into 1-page offset from the
beginning of that buffer . Finally, I'd check if exactly the size of the
file was changed in that buffer and the poisoned area of the buffer
still contains the poison or not.
|................poison................|
|
v
|...poison...|file...|.DZ.|...poison...|
If DZ is poison, everything is OK.
If DZ is 0x0, the ext4 corruption happened.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
From: David Rientjes @ 2018-07-23 21:33 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Yang Shi, Andrew Morton, kirill, hughd, aaron.lu, linux-mm,
linux-kernel
In-Reply-To: <alpine.DEB.2.21.1807231323460.105582@chino.kir.corp.google.com>
On Mon, 23 Jul 2018, David Rientjes wrote:
> > > The huge zero page can be reclaimed under memory pressure and, if it is,
> > > it is attempted to be allocted again with gfp flags that attempt memory
> > > compaction that can become expensive. If we are constantly under memory
> > > pressure, it gets freed and reallocated millions of times always trying to
> > > compact memory both directly and by kicking kcompactd in the background.
> > >
> > > It likely should also be per node.
> >
> > Have you benchmarked making the non-huge zero page per-node?
> >
>
> Not since we disable it :) I will, though. The more concerning issue for
> us, modulo CVE-2017-1000405, is the cpu cost of constantly directly
> compacting memory for allocating the hzp in real time after it has been
> reclaimed. We've observed this happening tens or hundreds of thousands
> of times on some systems. It will be 2MB per node on x86 if the data
> suggests we should make it NUMA aware, I don't think the cost is too high
> to leave it persistently available even under memory pressure if
> use_zero_page is enabled.
>
Measuring access latency to 4GB of memory on Naples I observe ~6.7%
slower access latency intrasocket and ~14% slower intersocket.
use_zero_page is currently a simple thp flag, meaning it rejects writes
where val != !!val, so perhaps it would be best to overload it with
additional options? I can imagine 0x2 defining persistent allocation so
that the hzp is not freed when the refcount goes to 0 and 0x4 defining if
the hzp should be per node. Implementing persistent allocation fixes our
concern with it, so I'd like to start there. Comments?
^ permalink raw reply
* [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:34 UTC (permalink / raw)
To: boris.ostrovsky, jgross; +Cc: Mark Railton, xen-devel, linux-kernel
Fixed issue with multi line comment
Signed-off-by: Mark Railton <mark@markrailton.com>
---
drivers/xen/xlate_mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 23f1387b3ef7..3b03bc1641ed 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct remap_data data;
unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
- /* Kept here for the purpose of making sure code doesn't break
- x86 PVOPS */
+ /* Kept here for the purpose of making sure code doesn't
+ * break x86 PVOPS
+ */
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
data.fgfn = gfn;
--
2.17.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:34 UTC (permalink / raw)
To: boris.ostrovsky, jgross; +Cc: xen-devel, linux-kernel, Mark Railton
Fixed issue with multi line comment
Signed-off-by: Mark Railton <mark@markrailton.com>
---
drivers/xen/xlate_mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 23f1387b3ef7..3b03bc1641ed 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
struct remap_data data;
unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
- /* Kept here for the purpose of making sure code doesn't break
- x86 PVOPS */
+ /* Kept here for the purpose of making sure code doesn't
+ * break x86 PVOPS
+ */
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
data.fgfn = gfn;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] arch/h8300: fix kernel/dma.c build warning
From: Richard Kuo @ 2018-07-23 21:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: Geert Uytterhoeven, open list:QUALCOMM HEXAGON...,
Linux Kernel Mailing List, Yoshinori Sato, Rich Felker,
Linux-sh list
In-Reply-To: <24723dd8-9d9f-24b7-6fe9-71a776c5d444@infradead.org>
On Sun, Jul 22, 2018 at 10:24:58AM -0700, Randy Dunlap wrote:
> On 07/22/2018 02:25 AM, Geert Uytterhoeven wrote:
> > CC hexagon
> >
> > hexagon != H8/300 != SuperH
>
> argh. Thanks.
>
> > On Sat, Jul 21, 2018 at 5:17 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
> >> to unsigned long to match the function parameter type.
> >>
> >> ../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
> >> ../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default]
> >> ../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> >> Cc: Rich Felker <dalias@libc.org>
> >> Cc: linux-sh@vger.kernel.org
> >> ---
> >> arch/hexagon/kernel/dma.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
Thanks all the same!
For Hexagon:
Acked-by: Richard Kuo <rkuo@codeaurora.org>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] arch/h8300: fix kernel/dma.c build warning
From: Richard Kuo @ 2018-07-23 21:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: Geert Uytterhoeven, open list:QUALCOMM HEXAGON...,
Linux Kernel Mailing List, Yoshinori Sato, Rich Felker,
Linux-sh list
In-Reply-To: <24723dd8-9d9f-24b7-6fe9-71a776c5d444@infradead.org>
On Sun, Jul 22, 2018 at 10:24:58AM -0700, Randy Dunlap wrote:
> On 07/22/2018 02:25 AM, Geert Uytterhoeven wrote:
> > CC hexagon
> >
> > hexagon != H8/300 != SuperH
>
> argh. Thanks.
>
> > On Sat, Jul 21, 2018 at 5:17 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
> >> to unsigned long to match the function parameter type.
> >>
> >> ../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
> >> ../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default]
> >> ../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> >> Cc: Rich Felker <dalias@libc.org>
> >> Cc: linux-sh@vger.kernel.org
> >> ---
> >> arch/hexagon/kernel/dma.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
Thanks all the same!
For Hexagon:
Acked-by: Richard Kuo <rkuo@codeaurora.org>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: Cédric Le Goater @ 2018-07-23 21:35 UTC (permalink / raw)
To: David Gibson
Cc: qemu-ppc, qemu-devel, Benjamin Herrenschmidt, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <20180718061230.GE2102@umbus.fritz.box>
>> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
>> index 6ac8a9392da6..966a996c2eac 100644
>> --- a/include/hw/ppc/xics.h
>> +++ b/include/hw/ppc/xics.h
>> @@ -194,6 +194,7 @@ void icp_set_mfrr(ICPState *icp, uint8_t mfrr);
>> uint32_t icp_accept(ICPState *ss);
>> uint32_t icp_ipoll(ICPState *ss, uint32_t *mfrr);
>> void icp_eoi(ICPState *icp, uint32_t xirr);
>> +void icp_irq(ICSState *ics, int server, int nr, uint8_t priority);
>
> Hrm... are you sure you need to expose this?
>
>> void ics_simple_write_xive(ICSState *ics, int nr, int server,
>> uint8_t priority, uint8_t saved_priority);
>> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
>> index b9f1a3c97214..59e2a5217dcc 100644
>> --- a/hw/intc/xics.c
>> +++ b/hw/intc/xics.c
>> @@ -230,7 +230,7 @@ void icp_eoi(ICPState *icp, uint32_t xirr)
>> }
>> }
>>
>> -static void icp_irq(ICSState *ics, int server, int nr, uint8_t priority)
>> +void icp_irq(ICSState *ics, int server, int nr, uint8_t priority)
>> {
>> ICPState *icp = xics_icp_get(ics->xics, server);
>>
[ ... ]
>> +
>> +static void phb3_msi_try_send(Phb3MsiState *msi, int srcno, bool ignore_p)
>> +{
>> + ICSState *ics = ICS_BASE(msi);
>> + uint64_t ive;
>> + uint64_t server, prio, pq, gen;
>> +
>> + if (!phb3_msi_read_ive(msi->phb, srcno, &ive)) {
>> + return;
>> + }
>> +
>> + server = GETFIELD(IODA2_IVT_SERVER, ive);
>> + prio = GETFIELD(IODA2_IVT_PRIORITY, ive);
>> + pq = GETFIELD(IODA2_IVT_Q, ive);
>> + if (!ignore_p) {
>> + pq |= GETFIELD(IODA2_IVT_P, ive) << 1;
>> + }
>> + gen = GETFIELD(IODA2_IVT_GEN, ive);
>> +
>> + /*
>> + * The low order 2 bits are the link pointer (Type II interrupts).
>> + * Shift back to get a valid IRQ server.
>> + */
>> + server >>= 2;
>> +
>> + switch (pq) {
>> + case 0: /* 00 */
>> + if (prio == 0xff) {
>> + /* Masked, set Q */
>> + phb3_msi_set_q(msi, srcno);
>> + } else {
>> + /* Enabled, set P and send */
>> + phb3_msi_set_p(msi, srcno, gen);
>> + icp_irq(ics, server, srcno + ics->offset, prio);
>
> Can't you just pulse the right qirq here, which will use the core ICS
> logic to propagate to the ICP?
The interrupt vector entries are maintained in the guest memory. We don't
have an entry in the device model (hcall, mmio on a register) to update
an IRQ state. So we need to find the target when the IRQ is triggered.
The interrupt source unit logic of the phb3 device is closer to the Type 3
architecture (XIVE) in fact.
C.
^ permalink raw reply
* [pull-request] next-net 18.08 RC2
From: Ferruh Yigit @ 2018-07-23 21:35 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit
The following changes since commit 711f43ba568acadf6cbccb9f8a29abf0fb3baa25:
examples/vm_power: make branch ratio configurable (2018-07-21 00:00:43 +0200)
are available in the Git repository at:
http://dpdk.org/git/next/dpdk-next-net
for you to fetch changes up to 2056d7a3d0de0548b0926231ed59fc072d387713:
net/mlx5: fix compilation issues on old kernels (2018-07-23 23:07:16 +0100)
----------------------------------------------------------------
Adrien Mazarguil (6):
net/mlx5: lay groundwork for switch offloads
net/mlx5: add framework for switch flow rules
net/mlx5: add fate actions to switch flow rules
net/mlx5: add L2-L4 pattern items to switch flow rules
net/mlx5: add VLAN item and actions to switch flow rules
net/mlx5: add port ID pattern item to switch flow rules
Andrew Rybchenko (5):
net/sfc: move Rx checksum offload check to device level
net/sfc: fix Rx queue offloads reporting in queue info
net/sfc: prepare to support Rx datapath without checksum
net/sfc: fix assert in set multicast address list
net/sfc: handle unknown L3 packet class in EF10 event parser
Beilei Xing (3):
net/i40e: fix PPPoL2TP packet type parser issue
net/i40e: fix packet type parser error
net/i40e: fix fail to set TPID with AQ command
Ferruh Yigit (3):
net/i40e: remove redundant queue id checks
net/fm10k: remove redundant queue id checks
net/ixgbe: remove redundant queue id checks
Gage Eads (2):
net/tap: set queue started and stopped
net/pcap: set queue started and stopped
Hyong Youb Kim (2):
doc: update the enic guide and features
net/enic: pick the right Rx handler after changing MTU
Igor Romanov (2):
net/sfc: fix filter exceptions logic
net/sfc: fallback to filter with zero vid
Jasvinder Singh (2):
ethdev: improve description for port name API
net/softnic: fix memory illegal access
Jerin Jacob (1):
ethdev: fix queue mapping documentation
Kiran Kumar (1):
net/thunderx: avoid sq door bell writes on zero packets
Moti Haimovsky (1):
net/mlx5: fix compilation issues on old kernels
Nelio Laranjeiro (2):
app/testpmd: add VXLAN encap/decap support
app/testpmd: add NVGRE encap/decap support
Pavan Nikhilesh (1):
net/thunderx: enable Rx checksum offload
Qi Zhang (1):
net/ixgbe: fix missing NULL point check
Radu Nicolau (1):
net/bonding: fix invalid port id
Rahul Lakkireddy (2):
net/cxgbe: update release notes for flow API support
net/cxgbe: fix init failure due to new flash parts
Rakesh Kudurumalla (1):
net/thunderx: add support for Rx VLAN offload
Rasesh Mody (1):
net/qede: move SPDX tags to source files
Shaopeng He (1):
net/i40e: fix Tx queue setup after stop queue
Tiwei Bie (1):
vhost: fix buffer length calculation
Wei Zhao (1):
net/i40e: fix FDIR check programming status error
Xiaoyun Li (2):
net/i40e: fix link speed issue
app/testpmd: fix little perf drop
app/test-pmd/cmdline.c | 345 +++++++
app/test-pmd/cmdline_flow.c | 274 ++++++
app/test-pmd/testpmd.c | 58 +-
app/test-pmd/testpmd.h | 32 +
doc/guides/nics/cxgbe.rst | 2 +-
doc/guides/nics/enic.rst | 76 +-
doc/guides/nics/features/enic.ini | 3 +
doc/guides/rel_notes/release_18_08.rst | 5 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 107 +++
drivers/net/bonding/rte_eth_bond_pmd.c | 2 +-
drivers/net/cxgbe/base/t4_hw.c | 97 +-
drivers/net/enic/enic_main.c | 25 +-
drivers/net/fm10k/fm10k_ethdev.c | 119 ++-
drivers/net/i40e/i40e_ethdev.c | 77 +-
drivers/net/i40e/i40e_ethdev_vf.c | 107 +--
drivers/net/i40e/i40e_fdir.c | 2 +
drivers/net/i40e/i40e_rxtx.c | 129 ++-
drivers/net/i40e/rte_pmd_i40e.c | 1 +
drivers/net/ixgbe/ixgbe_pf.c | 6 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 139 ++-
drivers/net/mlx5/Makefile | 187 ++++
drivers/net/mlx5/mlx5.c | 32 +
drivers/net/mlx5/mlx5.h | 28 +
drivers/net/mlx5/mlx5_defs.h | 5 +
drivers/net/mlx5/mlx5_ethdev.c | 26 +
drivers/net/mlx5/mlx5_flow.c | 111 +++
drivers/net/mlx5/mlx5_nl_flow.c | 1247 +++++++++++++++++++++++++
drivers/net/pcap/rte_eth_pcap.c | 49 +
drivers/net/qede/LICENSE.qede_pmd | 3 -
drivers/net/qede/Makefile | 3 +-
drivers/net/qede/base/bcm_osal.c | 4 +-
drivers/net/qede/base/bcm_osal.h | 4 +-
drivers/net/qede/base/common_hsi.h | 4 +-
drivers/net/qede/base/ecore.h | 4 +-
drivers/net/qede/base/ecore_attn_values.h | 4 +-
drivers/net/qede/base/ecore_chain.h | 4 +-
drivers/net/qede/base/ecore_cxt.c | 4 +-
drivers/net/qede/base/ecore_cxt.h | 4 +-
drivers/net/qede/base/ecore_cxt_api.h | 4 +-
drivers/net/qede/base/ecore_dcbx.c | 4 +-
drivers/net/qede/base/ecore_dcbx.h | 4 +-
drivers/net/qede/base/ecore_dcbx_api.h | 4 +-
drivers/net/qede/base/ecore_dev.c | 4 +-
drivers/net/qede/base/ecore_dev_api.h | 4 +-
drivers/net/qede/base/ecore_gtt_reg_addr.h | 4 +-
drivers/net/qede/base/ecore_gtt_values.h | 4 +-
drivers/net/qede/base/ecore_hsi_common.h | 4 +-
drivers/net/qede/base/ecore_hsi_debug_tools.h | 4 +-
drivers/net/qede/base/ecore_hsi_eth.h | 4 +-
drivers/net/qede/base/ecore_hsi_init_func.h | 4 +-
drivers/net/qede/base/ecore_hsi_init_tool.h | 4 +-
drivers/net/qede/base/ecore_hw.c | 4 +-
drivers/net/qede/base/ecore_hw.h | 4 +-
drivers/net/qede/base/ecore_hw_defs.h | 4 +-
drivers/net/qede/base/ecore_init_fw_funcs.c | 4 +-
drivers/net/qede/base/ecore_init_fw_funcs.h | 4 +-
drivers/net/qede/base/ecore_init_ops.c | 4 +-
drivers/net/qede/base/ecore_init_ops.h | 4 +-
drivers/net/qede/base/ecore_int.c | 4 +-
drivers/net/qede/base/ecore_int.h | 4 +-
drivers/net/qede/base/ecore_int_api.h | 4 +-
drivers/net/qede/base/ecore_iov_api.h | 4 +-
drivers/net/qede/base/ecore_iro.h | 4 +-
drivers/net/qede/base/ecore_iro_values.h | 4 +-
drivers/net/qede/base/ecore_l2.c | 4 +-
drivers/net/qede/base/ecore_l2.h | 4 +-
drivers/net/qede/base/ecore_l2_api.h | 4 +-
drivers/net/qede/base/ecore_mcp.c | 4 +-
drivers/net/qede/base/ecore_mcp.h | 4 +-
drivers/net/qede/base/ecore_mcp_api.h | 4 +-
drivers/net/qede/base/ecore_mng_tlv.c | 4 +-
drivers/net/qede/base/ecore_proto_if.h | 4 +-
drivers/net/qede/base/ecore_rt_defs.h | 4 +-
drivers/net/qede/base/ecore_sp_api.h | 4 +-
drivers/net/qede/base/ecore_sp_commands.c | 4 +-
drivers/net/qede/base/ecore_sp_commands.h | 4 +-
drivers/net/qede/base/ecore_spq.c | 4 +-
drivers/net/qede/base/ecore_spq.h | 4 +-
drivers/net/qede/base/ecore_sriov.c | 4 +-
drivers/net/qede/base/ecore_sriov.h | 4 +-
drivers/net/qede/base/ecore_status.h | 4 +-
drivers/net/qede/base/ecore_utils.h | 4 +-
drivers/net/qede/base/ecore_vf.c | 4 +-
drivers/net/qede/base/ecore_vf.h | 4 +-
drivers/net/qede/base/ecore_vf_api.h | 4 +-
drivers/net/qede/base/ecore_vfpf_if.h | 4 +-
drivers/net/qede/base/eth_common.h | 4 +-
drivers/net/qede/base/mcp_public.h | 4 +-
drivers/net/qede/base/nvm_cfg.h | 4 +-
drivers/net/qede/base/reg_addr.h | 4 +-
drivers/net/qede/qede_ethdev.c | 4 +-
drivers/net/qede/qede_ethdev.h | 4 +-
drivers/net/qede/qede_fdir.c | 4 +-
drivers/net/qede/qede_if.h | 4 +-
drivers/net/qede/qede_logs.h | 4 +-
drivers/net/qede/qede_main.c | 4 +-
drivers/net/qede/qede_rxtx.c | 4 +-
drivers/net/qede/qede_rxtx.h | 4 +-
drivers/net/sfc/sfc_dp_rx.h | 1 +
drivers/net/sfc/sfc_ef10_essb_rx.c | 3 +-
drivers/net/sfc/sfc_ef10_rx.c | 3 +-
drivers/net/sfc/sfc_ef10_rx_ev.h | 2 +
drivers/net/sfc/sfc_ethdev.c | 6 +-
drivers/net/sfc/sfc_filter.c | 14 +
drivers/net/sfc/sfc_filter.h | 10 +
drivers/net/sfc/sfc_flow.c | 92 +-
drivers/net/sfc/sfc_rx.c | 43 +-
drivers/net/softnic/rte_eth_softnic_swq.c | 5 +-
drivers/net/tap/rte_eth_tap.c | 56 +-
drivers/net/thunderx/base/nicvf_hw.c | 1 +
drivers/net/thunderx/nicvf_ethdev.c | 73 +-
drivers/net/thunderx/nicvf_ethdev.h | 1 +
drivers/net/thunderx/nicvf_rxtx.c | 144 ++-
drivers/net/thunderx/nicvf_rxtx.h | 24 +-
drivers/net/thunderx/nicvf_struct.h | 28 +-
lib/librte_ethdev/rte_ethdev.h | 23 +-
lib/librte_vhost/virtio_net.c | 8 +-
mk/rte.app.mk | 2 +-
118 files changed, 3445 insertions(+), 663 deletions(-)
create mode 100644 drivers/net/mlx5/mlx5_nl_flow.c
delete mode 100644 drivers/net/qede/LICENSE.qede_pmd
^ permalink raw reply
* Re: your mail
From: Bruce Fields @ 2018-07-23 20:33 UTC (permalink / raw)
To: Marc Eshel
Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list,
linux-nfs-owner
In-Reply-To: <OFA232E502.EADD3A82-ON882582D3.00667F9D-882582D3.0066E0F8@notes.na.collabserv.com>
On Mon, Jul 23, 2018 at 11:43:55AM -0700, Marc Eshel wrote:
> Do you know of any plans to add IETF RFC 8276 - File System Extended
> Attributes in NFSv4 to the Linux NFS Client or Server?
I don't understand why you proposed new protocol without having anyone
in mind to implement it on the platforms where you need it.
Matt Benjamin's expressed interest in the past, but he's got a lot on
his plate so I don't know that we can count on that.
--b.
^ permalink raw reply
* Re: [PATCH 02/14] format-patch: add --interdiff option to embed diff in cover letter
From: Junio C Hamano @ 2018-07-23 21:36 UTC (permalink / raw)
To: Eric Sunshine
Cc: Nguyễn Thái Ngọc Duy, Git List,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Stefan Beller
In-Reply-To: <CAPig+cRsPV+PGtkEM_c1b4P-NF7Dk7A8DvPVuvdbx4ESr3pmqg@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Mon, Jul 23, 2018 at 12:03 PM Duy Nguyen <pclouds@gmail.com> wrote:
>> On Sun, Jul 22, 2018 at 11:57 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>> > @@ -0,0 +1,17 @@
>> > +void show_interdiff(struct rev_info *rev)
>> > +{
>> > + struct diff_options opts;
>> > +
>> > + memcpy(&opts, &rev->diffopt, sizeof(opts));
>> > + opts.output_format = DIFF_FORMAT_PATCH;
>> > + diff_setup_done(&opts);
>> > +
>> > + diff_tree_oid(rev->idiff_oid1, rev->idiff_oid2, "", &opts);
>> > + diffcore_std(&opts);
>> > + diff_flush(&opts);
>> > +}
>>
>> Is it worth adding a new file just for a single function? I haven't
>> read the rest of the series, but the cover letter's diffstat suggests
>> this is it. Is interdiff intended to become a lot more complicated in
>> the future? If not maybe just add this function in diff-lib.c
>
> Good question. The functionality originally lived in builtin/log.c but
> moved to log-tree.c when I added the ability to embed an interdiff in
> a single patch. However, it didn't "feel" right in log-tree.c, so I
> moved it to its own file to mirror how the range-diff engine resides
> in its own file.
> And, the function actually did several more things as originally
> implemented. For instance, it took care of not clobbering global
> diff-queue state, and consulting 'reroll_count' and printing the
> "Interdiff:" header, but those bits eventually moved to live at more
> "correct" locations, leaving this relatively minimal function behind.
> It does get a bit more complex in a later patch, but not significantly
> so.
>
> I wasn't aware of diff-lib.c, but it does seem like show_interdiff()
> could be at home there.
Yeah, diff-lib.c is meant to be a home for the implementation of low
level "diff-{files,tree,index}" plumbing that can be called from
other routines; if you are adding "take two things, compare them"
that can be reused from places, then it is a good match.
^ permalink raw reply
* Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration
From: Junio C Hamano @ 2018-07-23 21:37 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <xmqq1sbt68ec.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
>> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
>> new file mode 100755
>> index 000000000..3cc93243f
>> --- /dev/null
>> +++ b/contrib/vscode/init.sh
>> @@ -0,0 +1,165 @@
>> +#!/bin/sh
>
> This is caued by our usual "git apply --whitespace=warn" as it
"caught"; sorry for a typo.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: Cédric Le Goater @ 2018-07-23 21:37 UTC (permalink / raw)
To: David Gibson
Cc: qemu-ppc, qemu-devel, Benjamin Herrenschmidt, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <20180718061230.GE2102@umbus.fritz.box>
On 07/18/2018 08:12 AM, David Gibson wrote:
>> +static void pnv_phb3_get_phb_id(Object *obj, Visitor *v, const char *name,
>> + void *opaque, Error **errp)
>> +{
>> + Property *prop = opaque;
>> + uint32_t *ptr = qdev_get_prop_ptr(DEVICE(obj), prop);
>> +
>> + visit_type_uint32(v, name, ptr, errp);
>> +}
>> +
>> +static void pnv_phb3_set_phb_id(Object *obj, Visitor *v, const char *name,
>> + void *opaque, Error **errp)
>> +{
>> + PnvPHB3 *phb = PNV_PHB3(obj);
>> + uint32_t phb_id;
>> + Error *local_err = NULL;
>> +
>> + visit_type_uint32(v, name, &phb_id, &local_err);
>> + if (local_err) {
>> + error_propagate(errp, local_err);
>> + return;
>> + }
>> +
>> + /*
>> + * Limit to a maximum of 6 PHBs per chip
>> + */
>> + if (phb_id >= PNV8_CHIP_PHB3_MAX) {
>> + error_setg(errp, "invalid PHB index: '%d'", phb_id);
>> + return;
>> + }
>> +
>> + phb->phb_id = phb_id;
>> +}
>> +
>> +static const PropertyInfo pnv_phb3_phb_id_propinfo = {
>> + .name = "irq",
>> + .get = pnv_phb3_get_phb_id,
>> + .set = pnv_phb3_set_phb_id,
>> +};
> Can't you use a static DeviceProps style property for this, which is a
> bit simpler?
yes but we will need these ops for user creatable devices. This is where
we will check the chip id.
C.
^ permalink raw reply
* Re: [PATCH] pack-objects: fix performance issues on packing large deltas
From: Jeff King @ 2018-07-23 21:37 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano, Elijah Newren
In-Reply-To: <CACsJy8AcDqNtV1VfHB+ZD=wvOxRyhobacreaNpjSm3NcLCMKWA@mail.gmail.com>
On Sat, Jul 21, 2018 at 06:23:32AM +0200, Duy Nguyen wrote:
> > I'm not sure I completely agree with this. While 4GB deltas should be
> > pretty rare, the nice thing about 64-bit is that you never have to even
> > think about whether the variable is large enough. I think the 2^32
> > limitations on Windows are something we should be fixing in the long
> > term (though there it is even worse because it is not just deltas, but
> > entire objects).
>
> I guess that means we stick to uint64_t then? It does increase more
> memory on 32-bit architecture (and probably processing cost as well
> because 64-bit uses up 2 registers).
Yes, but if we switch away from an array to a hash, then we get the best
of both worlds: we are using 64-bits to store the size, but we only need
an entry for deltas that are actually big.
Then the common small-delta case remains efficient in both CPU and
memory, and we pay the costs only in proportion to the number of large
deltas (though the hash is a slightly higher cost for those large deltas
than an array).
> > This is new in this iteration. I guess this is to cover the case where
> > we are built with pthread support, but --threads=1?
>
> If you mean the "lock_initialized" variable, not really. the other
> _lock() macros in builtin/ call pthread_mutex_lock() unconditionally,
> which is fine. But I feel a bit uncomfortable doing the same in
> pack-objects.h which technically is library code (but yes practically
> is a long arm of builtin/pack-objects.c), so lock_initialized is there
> to make sure we don't touch uninitialized locks if somebody forgets to
> init them first.
I think the ones in builtin/ check threads_active to avoid actually
locking. And that's set in init_thread(), which we do not call if we are
using a single thread. So I think this is basically doing the same
thing, but with a separate flag (since the library code does not know
about threads_active).
> > Your original patch had to copy the oe_* helpers into the file to handle
> > that. But I think we're essentially just locking the whole functions:
>
> I'll try to avoid this lock when deltas are small and see if it helps
> the linux.git case on Elijah's machine. So we may end up locking just
> a part of these functions.
Yeah, I think my suggestion doesn't work once we start doing more
complex locking logic. Let's just forget it. I think the
"lock_initialized" thing is probably the right approach.
It might be worth getting rid of builtin/pack-objects.c's local
threads_active variable, and just using to_pack.threads_active. The two
flag would always want to match.
-Peff
^ permalink raw reply
* [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 21:38 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <1532380412.4112.22.camel@HansenPartnership.com>
On 07/23/2018 02:13 PM, James Bottomley wrote:
> The current patch does, you even provided a use case in your last email
> (it's do command to get sizing followed by do command with correctly
> sized buffer).
The example I provided was: #1 send a command, #2 read the response header
(10 bytes), get the actual response size from the header and then #3 read
the full response (response size - size of the header bytes).
>
> However, if you tie it to O_NONBLOCK, it won't because no-one currently
> opens the TPM device non blocking so it's an ABI conformant
> discriminator of the uses. Tying to O_NONBLOCK should be simple
> because it's in file->f_flags.
I think that it might be an option. Especially that I have this on top of
the async patch. Let's discuss this when Jarkko is back.
Thanks,
--
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.