* 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
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Randy Dunlap @ 2018-07-23 21:38 UTC (permalink / raw)
To: Mark Railton, boris.ostrovsky, jgross; +Cc: xen-devel, linux-kernel
In-Reply-To: <20180723213404.20720-1-mark@markrailton.com>
On 07/23/2018 02:34 PM, Mark Railton wrote:
> Fixed issue with multi line comment
Fix [not Fixed]
>
> 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
> + */
That is still not the preferred kernel multi-line comment style.
Documentation/process/coding-style.rst says:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
although Networking code has a slightly different preferred style (as in
your patch).
> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>
> data.fgfn = gfn;
>
--
~Randy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Randy Dunlap @ 2018-07-23 21:38 UTC (permalink / raw)
To: Mark Railton, boris.ostrovsky, jgross; +Cc: xen-devel, linux-kernel
In-Reply-To: <20180723213404.20720-1-mark@markrailton.com>
On 07/23/2018 02:34 PM, Mark Railton wrote:
> Fixed issue with multi line comment
Fix [not Fixed]
>
> 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
> + */
That is still not the preferred kernel multi-line comment style.
Documentation/process/coding-style.rst says:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
although Networking code has a slightly different preferred style (as in
your patch).
> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>
> data.fgfn = gfn;
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates
From: Pavel Machek @ 2018-07-23 21:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joerg Roedel, Thomas Gleixner, Ingo Molnar, Peter Anvin,
the arch/x86 maintainers, Linux Kernel Mailing List, linux-mm,
Andrew Lutomirski, Dave Hansen, Josh Poimboeuf,
Jürgen Groß, Peter Zijlstra, Borislav Petkov,
Jiri Kosina, Boris Ostrovsky, Brian Gerst, David Laight,
Denys Vlasenko, Eduardo Valentin, Greg Kroah-Hartman, Will Deacon,
Liguori, Anthony, Daniel Gruss, Hugh Dickins, Kees Cook,
Andrea Arcangeli, Waiman Long, David H . Gutteridge, Joerg Roedel,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim
In-Reply-To: <CA+55aFynT9Sp7CbnB=GqLbns7GFZbv3pDSQm_h0jFvJpz3ES+g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]
On Mon 2018-07-23 12:00:08, Linus Torvalds wrote:
> On Mon, Jul 23, 2018 at 7:09 AM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Meanwhile... it looks like gcc is not slowed down significantly, but
> > other stuff sees 30% .. 40% slowdowns... which is rather
> > significant.
>
> That is more or less expected.
>
> Gcc spends about 90+% of its time in user space, and the system calls
> it *does* do tend to be "real work" (open/read/etc). And modern gcc's
> no longer have the pipe between cpp and cc1, so they don't have that
> issue either (which would have sjhown the PTI slowdown a lot more)
>
> Some other loads will do a lot more time traversing the user/kernel
> boundary, and in 32-bit mode you won't be able to take advantage of
> the address space ID's, so you really get the full effect.
Understood. Just -- bzip2 should include quite a lot of time in
userspace, too.
> > Would it be possible to have per-process control of kpti? I have
> > some processes where trading of speed for security would make sense.
>
> That was pretty extensively discussed, and no sane model for it was
> ever agreed upon. Some people wanted it per-thread, others per-mm,
> and it wasn't clear how to set it either and how it should inherit
> across fork/exec, and what the namespace rules etc should be.
>
> You absolutely need to inherit it (so that you can say "I trust this
> session" or whatever), but at the same time you *don't* want to
> inherit if you have a server you trust that then spawns user processes
> (think "I want systemd to not have the overhead, but the user
> processes it spawns obviously do need protection").
>
> It was just a morass. Nothing came out of it. I guess people can
> discuss it again, but it's not simple.
I agree it is not easy. OTOH -- 30% of user-visible performance is a
_lot_. That is worth spending man-years on... Ok, problem is not as
severe on modern CPUs with address space ID's, but...
What I want is "if A can ptrace B, and B has pti disabled, A can have
pti disabled as well". Now.. I see someone may want to have it
per-thread, because for stuff like javascript JIT, thread may have
rights to call ptrace, but is unable to call ptrace because JIT
removed that ability... hmm...
But for now I'd like at least "global" option of turning pti on/off
during runtime for benchmarking. Let me see...
Something like this, or is it going to be way more complex? Does
anyone have patch by chance?
Pavel
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index dfb975b..719e39a 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -162,6 +162,9 @@
.macro SWITCH_TO_USER_CR3 scratch_reg:req
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
+ cmpl $1, PER_CPU_VAR(pti_enabled)
+ jne .Lend_\@
+
movl %cr3, \scratch_reg
orl $PTI_SWITCH_MASK, \scratch_reg
movl \scratch_reg, %cr3
@@ -176,6 +179,8 @@
testl $SEGMENT_RPL_MASK, PT_CS(%esp)
jz .Lend_\@
.endif
+ cmpl $1, PER_CPU_VAR(pti_enabled)
+ jne .Lend_\@
/* On user-cr3? */
movl %cr3, %eax
testl $PTI_SWITCH_MASK, %eax
@@ -192,6 +197,10 @@
*/
.macro SWITCH_TO_KERNEL_CR3 scratch_reg:req
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
+
+ cmpl $1, PER_CPU_VAR(pti_enabled)
+ jne .Lend_\@
+
movl %cr3, \scratch_reg
/* Test if we are already on kernel CR3 */
testl $PTI_SWITCH_MASK, \scratch_reg
@@ -302,6 +311,9 @@
*/
ALTERNATIVE "jmp .Lswitched_\@", "", X86_FEATURE_PTI
+ cmpl $1, PER_CPU_VAR(pti_enabled)
+ jne .Lswitched_\@
+
testl $PTI_SWITCH_MASK, \cr3_reg
jz .Lswitched_\@
diff --git a/arch/x86/include/asm/cpu_entry_area.h b/arch/x86/include/asm/cpu_entry_area.h
index 4a7884b..8c92ae2 100644
--- a/arch/x86/include/asm/cpu_entry_area.h
+++ b/arch/x86/include/asm/cpu_entry_area.h
@@ -59,6 +59,7 @@ struct cpu_entry_area {
#define CPU_ENTRY_AREA_TOT_SIZE (CPU_ENTRY_AREA_SIZE * NR_CPUS)
DECLARE_PER_CPU(struct cpu_entry_area *, cpu_entry_area);
+DECLARE_PER_CPU(int, pti_enabled);
extern void setup_cpu_entry_areas(void);
extern void cea_set_pte(void *cea_vaddr, phys_addr_t pa, pgprot_t flags);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f73fa6f..da34a21 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -507,6 +507,9 @@ void load_percpu_segment(int cpu)
DEFINE_PER_CPU(struct cpu_entry_area *, cpu_entry_area);
#endif
+DEFINE_PER_CPU(int, pti_enabled);
+
+
#ifdef CONFIG_X86_64
/*
* Special IST stacks which the CPU switches to when it calls
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH] IPoIB: use kvzalloc to allocate an array of bucket pointers
From: Jason Gunthorpe @ 2018-07-23 21:38 UTC (permalink / raw)
To: Jan Dakinevich
Cc: Doug Ledford, Leon Romanovsky, Yuval Shaia, Alex Vesker,
Erez Shitrit, Feras Daoud, Kees Cook, Evgenii Smirnov, linux-rdma,
linux-kernel, Denis Lunev, Konstantin Khorenko
In-Reply-To: <1531144263-24717-1-git-send-email-jan.dakinevich@virtuozzo.com>
On Mon, Jul 09, 2018 at 04:51:03PM +0300, Jan Dakinevich wrote:
> This table by default takes 32KiB which is 3rd memory order. Meanwhile,
> this memory is not aimed for DMA operation and could be safely allocated
> by vmalloc.
>
> Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
> Reviewed-by: Håkon Bugge <haakon.bugge@oracle.com>
> ---
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied to for-next, thanks
Jason
^ 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:38 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:
>> + /* Setup LSI offset */
>> + ics->offset = comp + global;
> Oh.. changing ICS offset at runtime. I hadn't considered that case..
Yes. The PowerNV FW defines the IRQ layout in the overall number space.
C.
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:40 UTC (permalink / raw)
To: Randy Dunlap; +Cc: jgross, xen-devel, boris.ostrovsky, linux-kernel
In-Reply-To: <e0b30ab8-d418-cbe0-d03c-a0aee1d48367@infradead.org>
On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
> On 07/23/2018 02:34 PM, Mark Railton wrote:
> > Fixed issue with multi line comment
>
> Fix [not Fixed]
>
> >
> > 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
> > + */
>
> That is still not the preferred kernel multi-line comment style.
> Documentation/process/coding-style.rst says:
>
> /*
> * This is the preferred style for multi-line
> * comments in the Linux kernel source code.
> * Please use it consistently.
> *
> * Description: A column of asterisks on the left side,
> * with beginning and ending almost-blank lines.
> */
>
> although Networking code has a slightly different preferred style (as in
> your patch).
>
> > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >
> > data.fgfn = gfn;
> >
>
>
> --
> ~Randy
Thank's for the feedback, I'll get that updated now.
I'm still kinda new to this, I assume I need to send the new patch via
git send-email?
Thanks,
Mark
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ 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.