* Hello
From: John M. @ 2019-06-20 14:30 UTC (permalink / raw)
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
Good Day.
I know reading my email, will be surprising to you and your
entire family, but please take whatever I am about to share with
you today seriously.
My name is John Mobutu, I am 22 years old, from Congo, my parents
were assassinated by opposition leaders many years ago, but thank
God the United Nations Peace Keeping, who came to rescue me and
my younger sister to Kenya, where we have been living presently.
My late father was into Gold and Diamond mining, while my late
mother was a Government worker.
My four consignment boxes containing 182 Million USD and 2,300
kilogram of gold was ship to the United Sates of America, three
weeks ago for delivery to Mr. Barry Miller, in Atlanta Ga, by
the United Nations Head Office in Africa, which is in Kenya, but
up till now the agents haven't been able to reach my beneficiary
and they are threatening to return my money and gold back to
Kenya, I am very disappointed and confuse right now, this is pure
evil.
Please I really need your assistance right now, if you are
willing to help us, kindly get back to us immediately for more
discussion.
Please kindly tell us more about yourself when replying to our
email. Thanks
God bless you
Sincerely
John
^ permalink raw reply
* Re: [PATCH v2] treewide: remove CONFIG_DEBUG_INFO from defconfigs
From: Sascha Hauer @ 2019-06-20 14:29 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: barebox, Oleksij Rempel
In-Reply-To: <20190620085421.GA26493@ravnborg.org>
On Thu, Jun 20, 2019 at 10:54:21AM +0200, Sam Ravnborg wrote:
> Hi Antony
>
> On Thu, Jun 20, 2019 at 11:25:09AM +0300, Antony Pavlov wrote:
> > The commit b917f7864115a35 ("remove CONFIG_DEBUG_INFO")
> > has dropped Kconfig DEBUG_INFO option however we
> > still have very many DEBUG_INFO mentions in defconfig
> > files. Drop them using sed:
> >
> > find -iname '*defconfig' -type f -exec \
> > sed -i "/CONFIG_DEBUG_INFO=y/d" {} ';'
> Another approach could be to regenerate all defconfigs.
> A little scripting around savedefconfig should do it.
>
> Then we would get rid of all obsolete symbols in one go - for all
> defconfigs.
>
> The generated defconfig would be the one that people would be using
> anyway, so there should be only a little risk to introduce new issues
> doing it this way.
>
> Willing to try this approcah - maybe across all architectures?
I once thought the same and came up with this little thing:
#!/bin/bash
for a in arch/*; do
arch=$(basename $a)
for c in $a/configs/*; do
config=$(basename $c)
export ARCH=$arch
make $config && make savedefconfig && mv defconfig $c
done
done
Just tested, still works. Maybe I should just run this from time to time
and commit the result. What do you think?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v2] ipsec: support multi-segment packets
From: Ananyev, Konstantin @ 2019-06-20 14:29 UTC (permalink / raw)
To: Akhil Goyal, dev@dpdk.org
In-Reply-To: <VE1PR04MB66395F637E740C5D9D930A7FE6E40@VE1PR04MB6639.eurprd04.prod.outlook.com>
Hi Akhil,
> Hi Konstantin,
>
> >
> > Add support for packets that consist of multiple segments.
> > Take into account that trailer bytes (padding, ESP tail, ICV)
> > can spawn across multiple segments.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
>
> Which all action types does this patch work well with?
> Will it work for lookaside none and inline crypto case both?
Yes, in theory it should work with any device that supports
in-place SGL.
On practice, right now I am not aware about inline-crypto devices
that can support such feature.
So far, tested with lookaside-none device.
> For the other 2, ipsec lib is not used.
In fact, ipsec lib can be used by all 4 cases I believe.
Though as I udenstand for lookaside-proto and inline-proto
nothing need to be added/changed inside the lib
(as HW supposed to deal with it transparently).
>
> Also how can the SG support be tested?
Here is a separate patch series that adds fragmentation/reassembly
support into ipsec-secgw and updates test-scripts with new test-cases:
http://patches.dpdk.org/cover/54491/
>
> >
> > v1 -> v2:
> > merge with latest mainline
> > fix build problem for RTE_BUILD_SHARED_LIB=y
> > update programmer's guide
> >
> > doc/guides/prog_guide/ipsec_lib.rst | 1 -
> > lib/librte_ipsec/Makefile | 3 +-
> > lib/librte_ipsec/esp_inb.c | 148 +++++++++++++++++++++-------
> > lib/librte_ipsec/misc.h | 61 ++++++++++++
> > 4 files changed, 175 insertions(+), 38 deletions(-)
> >
> > diff --git a/doc/guides/prog_guide/ipsec_lib.rst
> > b/doc/guides/prog_guide/ipsec_lib.rst
> > index 6fc08886f..63b75b652 100644
> > --- a/doc/guides/prog_guide/ipsec_lib.rst
> > +++ b/doc/guides/prog_guide/ipsec_lib.rst
> > @@ -162,7 +162,6 @@ Limitations
> > The following features are not properly supported in the current version:
> >
> > * ESP transport mode for IPv6 packets with extension headers.
> > -* Multi-segment packets.
> > * Updates of the fields in inner IP header for tunnel mode
> > (as described in RFC 4301, section 5.1.2).
> > * Hard/soft limit for SA lifetime (time interval/byte count).
> > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> > index e80926baa..22f29d98a 100644
> > --- a/lib/librte_ipsec/Makefile
> > +++ b/lib/librte_ipsec/Makefile
> > @@ -9,7 +9,8 @@ LIB = librte_ipsec.a
> > CFLAGS += -O3
> > CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
> > CFLAGS += -DALLOW_EXPERIMENTAL_API
> > -LDLIBS += -lrte_eal -lrte_mbuf -lrte_net -lrte_cryptodev -lrte_security
> > +LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_net
> > +LDLIBS += -lrte_cryptodev -lrte_security
> >
>
> I believe this build dependency should also be updated in meson.build file as well.
I found that unnecessary, meson seems to be able to figure out implicit dependencies itself.
Though if you strongly insist, I can add them.
Konstantin
^ permalink raw reply
* Re: [PATCH stable-4.4 v3] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
From: Greg KH @ 2019-06-20 14:29 UTC (permalink / raw)
To: Michal Hocko
Cc: Stable tree, Jason Gunthorpe, linux-mm, LKML, Andrea Arcangeli,
Jann Horn, Oleg Nesterov, Peter Xu, Mike Rapoport, Michal Hocko,
Andrew Morton, Linus Torvalds, Joel Fernandes
In-Reply-To: <20190617065824.28305-1-mhocko@kernel.org>
On Mon, Jun 17, 2019 at 08:58:24AM +0200, Michal Hocko wrote:
> From: Andrea Arcangeli <aarcange@redhat.com>
>
> Upstream 04f5866e41fb70690e28397487d8bd8eea7d712a commit.
>
> The core dumping code has always run without holding the mmap_sem for
> writing, despite that is the only way to ensure that the entire vma
> layout will not change from under it. Only using some signal
> serialization on the processes belonging to the mm is not nearly enough.
> This was pointed out earlier. For example in Hugh's post from Jul 2017:
>
> https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
>
> "Not strictly relevant here, but a related note: I was very surprised
> to discover, only quite recently, how handle_mm_fault() may be called
> without down_read(mmap_sem) - when core dumping. That seems a
> misguided optimization to me, which would also be nice to correct"
>
> In particular because the growsdown and growsup can move the
> vm_start/vm_end the various loops the core dump does around the vma will
> not be consistent if page faults can happen concurrently.
>
> Pretty much all users calling mmget_not_zero()/get_task_mm() and then
> taking the mmap_sem had the potential to introduce unexpected side
> effects in the core dumping code.
>
> Adding mmap_sem for writing around the ->core_dump invocation is a
> viable long term fix, but it requires removing all copy user and page
> faults and to replace them with get_dump_page() for all binary formats
> which is not suitable as a short term fix.
>
> For the time being this solution manually covers the places that can
> confuse the core dump either by altering the vma layout or the vma flags
> while it runs. Once ->core_dump runs under mmap_sem for writing the
> function mmget_still_valid() can be dropped.
>
> Allowing mmap_sem protected sections to run in parallel with the
> coredump provides some minor parallelism advantage to the swapoff code
> (which seems to be safe enough by never mangling any vma field and can
> keep doing swapins in parallel to the core dumping) and to some other
> corner case.
>
> In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
> however the side effect of this same race condition in /proc/pid/mem
> should be reproducible since before 2.6.12-rc2 so I couldn't add any
> other "Fixes:" because there's no hash beyond the git genesis commit.
>
> Because find_extend_vma() is the only location outside of the process
> context that could modify the "mm" structures under mmap_sem for
> reading, by adding the mmget_still_valid() check to it, all other cases
> that take the mmap_sem for reading don't need the new check after
> mmget_not_zero()/get_task_mm(). The expand_stack() in page fault
> context also doesn't need the new check, because all tasks under core
> dumping are frozen.
>
> Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
> Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> Reported-by: Jann Horn <jannh@google.com>
> Suggested-by: Oleg Nesterov <oleg@redhat.com>
> Acked-by: Peter Xu <peterx@redhat.com>
> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> Reviewed-by: Oleg Nesterov <oleg@redhat.com>
> Reviewed-by: Jann Horn <jannh@google.com>
> Acked-by: Jason Gunthorpe <jgg@mellanox.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
> [mhocko@suse.com: stable 4.4 backport
> - drop infiniband part because of missing 5f9794dc94f59
> - drop userfaultfd_event_wait_completion hunk because of
> missing 9cd75c3cd4c3d]
> - handle binder_update_page_range because of missing 720c241924046
> - handle mlx5_ib_disassociate_ucontext - akaher@vmware.com
> ]
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> drivers/android/binder.c | 6 ++++++
> drivers/infiniband/hw/mlx4/main.c | 3 +++
> fs/proc/task_mmu.c | 18 ++++++++++++++++++
> fs/userfaultfd.c | 10 ++++++++--
> include/linux/mm.h | 21 +++++++++++++++++++++
> mm/mmap.c | 7 ++++++-
> 6 files changed, 62 insertions(+), 3 deletions(-)
I've queued this up now, as it looks like everyone agrees with it. What
about a 4.9.y backport?
thanks,
greg k-h
^ permalink raw reply
* [Buildroot] [git commit] package/brotli: properly pass TARGET_CFLAGS in Microblaze workaround
From: Thomas Petazzoni @ 2019-06-20 14:29 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=657ffee375f4751a760b28795c7064e89b882147
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
In commit 39dde1ffb6a7111c2fa2b340c940e4d3e685aa29 ("package/brotli:
work around gcc bug 68485"), a mistake was made: when
BR2_TOOLCHAIN_HAS_GCC_BUG_68485=y, we're only passing -O0 as CFLAGS,
completely ignoring TARGET_CFLAGS, which is not good.
This commit fixes that by introducing a BROTLI_CFLAGS variable,
initially defined to TARGET_CFLAGS, and to which we add -O0 when
BR2_TOOLCHAIN_HAS_GCC_BUG_68485=y.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
[Thomas: rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/brotli/brotli.mk | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/package/brotli/brotli.mk b/package/brotli/brotli.mk
index 248bfb9daf..134f480895 100644
--- a/package/brotli/brotli.mk
+++ b/package/brotli/brotli.mk
@@ -14,8 +14,12 @@ BROTLI_CONF_OPTS = \
-DBROTLI_DISABLE_TESTS=ON \
-DBROTLI_BUNDLED_MODE=OFF
+BROTLI_CFLAGS = $(TARGET_CFLAGS)
+
ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_68485),y)
-BROTLI_CONF_OPTS += -DCMAKE_C_FLAGS="-O0"
+BROTLI_CFLAGS += -O0
endif
+BROTLI_CONF_OPTS += -DCMAKE_C_FLAGS="$(BROTLI_CFLAGS)"
+
$(eval $(cmake-package))
^ permalink raw reply related
* Re: [PATCH] FMC: fix 'passing zero to PTR_ERR()' warning
From: Alessandro Rubini @ 2019-06-20 14:28 UTC (permalink / raw)
To: dingxiang; +Cc: linux-kernel
In-Reply-To: <1561025421-19655-1-git-send-email-dingxiang@cmss.chinamobile.com>
Hello.
drivers/fmc is going to be removed from the official kernel (removal
is queued by Linus Walleij, with approval by fmc authors).
So this patch should be dropped.
thanks
/alessandro
^ permalink raw reply
* [PATCH v7 0/5] Basic DT support for Lenovo Miix 630
From: Jeffrey Hugo @ 2019-06-20 14:28 UTC (permalink / raw)
Cc: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede,
bjorn.andersson, agross, lee.jones, xnox, robh+dt, mark.rutland,
linux-input, devicetree, linux-arm-msm, Jeffrey Hugo
The Lenovo Miix 630 is one of three ARM based (specifically Qualcomm
MSM8998) laptops that comes with Windows, and seems to have a dedicated
following of folks intrested to get Linux up and running on it.
This series adds support for the basic functionality this is validated
towork using devicetree. Although the laptops do feed ACPI to Windows,
the existing MSM8998 support in mainline is DT based, so DT provides a
quick path to functionality while ACPI support is investigated.
The three devices are very similar, but do have differences in the set
of peripherals supported, so the idea is that the vast majority of the
support for all three can live in a common include, which should reduce
overall duplication. Adding support for the other two devices is tacked
onto the end of the series.
The bleeding edge work for these laptops and work in progress can be
found at https://github.com/aarch64-laptops/prebuilt
v7:
-Removed HID matching on compatible strings as it was determined to be
not needed
v6:
-Export the elan_i2c DT and ACPI ids so that hid-quirks can use them
-Use the elan_i2c ids within hid-quirks to reduce duplication
-Add DTs for the Asus and HP devices since the DT seems finalized, and
folks have been asking
v5:
-Split out elan_i2c changes into their own patch
-Use a static list of strings to match
-Fixed typo of "whitelist"
-Dropped incorrect thermal zones
-Dropped tags from Bjorn and Lee since the functional should be
identical, but the code is structured different
v4:
-Changed the hid-quirks ELAN handling around per Benjamin Tissoires
-Dropped new DT binding
v3:
-Changed "clam" to "clamshell"
-Defined a dt binding for the combo Elan keyboard + touchpad device
-Adjusted the HID quirk to be correct for dt boot
-Removed extranious comment in board dts
-Fixed board level compatible
v2:
-Changed "cls" to "clam" since feedback indicated "cls" is too opaque,
but
"clamshell" is a mouthfull. "clam" seems to be a happy medium.
Jeffrey Hugo (5):
Input: elan_i2c: Export the device id whitelist
HID: quirks: Refactor ELAN 400 and 401 handling
arm64: dts: qcom: Add Lenovo Miix 630
arm64: dts: qcom: Add HP Envy x2
arm64: dts: qcom: Add Asus NovaGo TP370QL
arch/arm64/boot/dts/qcom/Makefile | 3 +
.../dts/qcom/msm8998-asus-novago-tp370ql.dts | 47 ++++
.../boot/dts/qcom/msm8998-clamshell.dtsi | 240 ++++++++++++++++++
.../boot/dts/qcom/msm8998-hp-envy-x2.dts | 30 +++
.../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 +++
drivers/hid/hid-quirks.c | 22 +-
drivers/input/mouse/elan_i2c_core.c | 54 +---
include/linux/input/elan-i2c-ids.h | 68 +++++
8 files changed, 430 insertions(+), 64 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
create mode 100644 include/linux/input/elan-i2c-ids.h
--
2.17.1
^ permalink raw reply
* [PATCH v7 0/5] Basic DT support for Lenovo Miix 630
From: Jeffrey Hugo @ 2019-06-20 14:28 UTC (permalink / raw)
Cc: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede,
bjorn.andersson, agross, lee.jones, xnox, robh+dt, mark.rutland,
linux-input, devicetree, linux-arm-msm, Jeffrey Hugo
The Lenovo Miix 630 is one of three ARM based (specifically Qualcomm
MSM8998) laptops that comes with Windows, and seems to have a dedicated
following of folks intrested to get Linux up and running on it.
This series adds support for the basic functionality this is validated
towork using devicetree. Although the laptops do feed ACPI to Windows,
the existing MSM8998 support in mainline is DT based, so DT provides a
quick path to functionality while ACPI support is investigated.
The three devices are very similar, but do have differences in the set
of peripherals supported, so the idea is that the vast majority of the
support for all three can live in a common include, which should reduce
overall duplication. Adding support for the other two devices is tacked
onto the end of the series.
The bleeding edge work for these laptops and work in progress can be
found at https://github.com/aarch64-laptops/prebuilt
v7:
-Removed HID matching on compatible strings as it was determined to be
not needed
v6:
-Export the elan_i2c DT and ACPI ids so that hid-quirks can use them
-Use the elan_i2c ids within hid-quirks to reduce duplication
-Add DTs for the Asus and HP devices since the DT seems finalized, and
folks have been asking
v5:
-Split out elan_i2c changes into their own patch
-Use a static list of strings to match
-Fixed typo of "whitelist"
-Dropped incorrect thermal zones
-Dropped tags from Bjorn and Lee since the functional should be
identical, but the code is structured different
v4:
-Changed the hid-quirks ELAN handling around per Benjamin Tissoires
-Dropped new DT binding
v3:
-Changed "clam" to "clamshell"
-Defined a dt binding for the combo Elan keyboard + touchpad device
-Adjusted the HID quirk to be correct for dt boot
-Removed extranious comment in board dts
-Fixed board level compatible
v2:
-Changed "cls" to "clam" since feedback indicated "cls" is too opaque,
but
"clamshell" is a mouthfull. "clam" seems to be a happy medium.
Jeffrey Hugo (5):
Input: elan_i2c: Export the device id whitelist
HID: quirks: Refactor ELAN 400 and 401 handling
arm64: dts: qcom: Add Lenovo Miix 630
arm64: dts: qcom: Add HP Envy x2
arm64: dts: qcom: Add Asus NovaGo TP370QL
arch/arm64/boot/dts/qcom/Makefile | 3 +
.../dts/qcom/msm8998-asus-novago-tp370ql.dts | 47 ++++
.../boot/dts/qcom/msm8998-clamshell.dtsi | 240 ++++++++++++++++++
.../boot/dts/qcom/msm8998-hp-envy-x2.dts | 30 +++
.../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 +++
drivers/hid/hid-quirks.c | 22 +-
drivers/input/mouse/elan_i2c_core.c | 54 +---
include/linux/input/elan-i2c-ids.h | 68 +++++
8 files changed, 430 insertions(+), 64 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
create mode 100644 include/linux/input/elan-i2c-ids.h
--
2.17.1
^ permalink raw reply
* Re: [PATCH 04/14] ABI: better identificate tables
From: Mauro Carvalho Chehab @ 2019-06-20 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Johan Hovold, Linux Doc Mailing List, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Stefan Achatz
In-Reply-To: <20190619131408.26b45c3b@coco.lan>
Em Wed, 19 Jun 2019 13:14:08 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> Em Wed, 19 Jun 2019 17:02:07 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Wed, Jun 19, 2019 at 10:56:33AM -0300, Mauro Carvalho Chehab wrote:
> > > Hi Johan,
> > >
> > > Em Wed, 19 Jun 2019 14:51:35 +0200
> > > Johan Hovold <johan@kernel.org> escreveu:
> > >
> > > > On Thu, Jun 13, 2019 at 11:04:10PM -0300, Mauro Carvalho Chehab wrote:
> > > > > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > > > >
> > > > > When parsing via script, it is important to know if the script
> > > > > should consider a description as a literal block that should
> > > > > be displayed as-is, or if the description can be considered
> > > > > as a normal text.
> > > > >
> > > > > Change descriptions to ensure that the preceding line of a table
> > > > > ends with a colon. That makes easy to identify the need of a
> > > > > literal block.
> > > >
> > > > In the cover letter you say that the first four patches of this series,
> > > > including this one, "fix some ABI descriptions that are violating the
> > > > syntax described at Documentation/ABI/README". This seems a bit harsh,
> > > > given that it's you that is now *introducing* a new syntax requirement
> > > > to assist your script.
> > >
> > > Yeah, what's there at the cover letter doesn't apply to this specific
> > > patch. The thing is that I wrote this series a lot of time ago (2016/17).
> > >
> > > I revived those per a request at KS ML, as we still need to expose the
> > > ABI content on some book that will be used by userspace people.
> > >
> > > So, I just rebased it on the top of curent Kernel, add a cover letter
> > > with the things I remembered and re-sent.
> > >
> > > In the specific case of this patch, the ":" there actually makes sense
> > > for someone that it is reading it as a text file, and it is an easy
> > > hack to make it parse better.
> > >
> > > > Specifically, this new requirement isn't documented anywhere AFAICT, so
> > > > how will anyone adding new ABI descriptions learn about it?
> > >
> > > Yeah, either that or provide an alternative to "Description" tag, to be
> > > used with more complex ABI descriptions.
> > >
> > > One of the things that occurred to me, back on 2017, is that we should
> > > have a way to to specify that an specific ABI description would have
> > > a rich format. Something like:
> > >
> > > What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
> > > Date: August 2010
> > > Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
> > > RST-Description:
> > > It is possible to switch the cpi setting of the mouse with the
> > > press of a button.
> > > When read, this file returns the raw number of the actual cpi
> > > setting reported by the mouse. This number has to be further
> > > processed to receive the real dpi value:
> > >
> > > ===== =====
> > > VALUE DPI
> > > ===== =====
> > > 1 400
> > > 2 800
> > > 4 1600
> > > ===== =====
> > >
> > > With that, the script will know that the description contents will be using
> > > the ReST markup, and parse it accordingly. Right now, what it does, instead,
> > > is to place the description on a code-block, e. g. it will produce this
> > > output for the description:
> > >
> > > ::
> > >
> > > It is possible to switch the cpi setting of the mouse with the
> > > press of a button.
> > > When read, this file returns the raw number of the actual cpi
> > > setting reported by the mouse. This number has to be further
> > > processed to receive the real dpi value:
> > >
> > > VALUE DPI
> > > 1 400
> > > 2 800
> > > 4 1600
> > >
> > >
> > > Greg,
> > >
> > > what do you think?
> >
> > I don't know when "Description" and "RST-Description" would be used.
> > Why not just parse "Description" like rst text and if things are "messy"
> > we fix them up as found, like you did with the ":" here? It doesn't
> > have to be complex, we can always fix them up after-the-fact if new
> > stuff gets added that doesn't quite parse properly.
> >
> > Just like we do for most kernel-doc formatting :)
>
> Works for me. Yet, I guess I tried that, back on 2017.
>
> If I'm not mistaken, the initial patchset to solve the broken things
> won't be small, and will be require a lot of attention in order to
> identify what's broken and where.
>
> Btw, one thing is to pass at ReST validation. Another thing is to
> produce something that people can read.
>
> Right now, the pertinent logic at the script I wrote (scripts/get_abi.pl)
> is here:
>
> if (!($desc =~ /^\s*$/)) {
> if ($desc =~ m/\:\n/ || $desc =~ m/\n[\t ]+/ || $desc =~ m/[\x00-\x08\x0b-\x1f\x7b-\xff]/) {
> # put everything inside a code block
> $desc =~ s/\n/\n /g;
>
> print "::\n\n";
> print " $desc\n\n";
> } else {
> # Escape any special chars from description
> $desc =~s/([\x00-\x08\x0b-\x1f\x21-\x2a\x2d\x2f\x3c-\x40\x5c\x5e-\x60\x7b-\xff])/\\$1/g;
>
> print "$desc\n\n";
> }
> }
>
> If it discovers something weird enough, it just places everything
> into a comment block. Otherwise, it assumes that it is a plain
> text and that any special characters should be escaped.
>
> If the above block is replaced by a simple:
>
> print "$desc\n\n";
>
> The description content will be handled as a ReST file.
>
> I don't have any time right now to do this change and to handle the
> warnings that will start to popup.
>
> Btw, a single replace there is enough to show the amount of problems that
> it will rise, as it will basically break Sphinx build with:
>
> reading sources... [ 1%] admin-guide/abi-testing
> reST markup error:
> get_abi.pl rest --dir $srctree/Documentation/ABI/testing:45261: (SEVERE/4) Missing matching underline for section title overline.
>
> ==========================
> PCIe Device AER statistics
> These attributes show up under all the devices that are AER capable. These
To be clear here: the problem with the above is that ReST has zero
tolerance and actually behaves like a crash, if it receives something like:
==========================
PCIe Device AER statistics
==========================
For it to work, it has to have zero spaces before ===..=== line, e. g.:
==========================
PCIe Device AER statistics
==========================
Ok, maybe we could try to teach the parser a way to identify the initial
spacing of the first description line and remove that amount of
spaces/tabs for the following lines, but it may require some heuristics.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH V6 04/27] PCI: tegra: Mask AFI_INTR in runtime suspend
From: Lorenzo Pieralisi @ 2019-06-20 14:27 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: thierry.reding, bhelgaas, robh+dt, mark.rutland, jonathanh,
vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190618180206.4908-5-mmaddireddy@nvidia.com>
On Tue, Jun 18, 2019 at 11:31:43PM +0530, Manikanta Maddireddy wrote:
> AFI_INTR is unmasked in tegra_pcie_enable_controller(), mask it to avoid
> unwanted interrupts raised by AFI after pex_rst is asserted.
>
> Following sequence triggers such scenario,
> - tegra_pcie_remove() triggers runtime suspend
> - pex_rst is asserted in runtime suspend
> - PRSNT_MAP bit field in RP_PRIV_MISC register changes from EP_PRSNT to
> EP_ABSNT
> - This is sensed by AFI and triggers "Slot present pin change" interrupt
> - tegra_pcie_isr() function accesses AFI register when runtime suspend
> is going through power off sequence
>
> rmmod pci-tegra
> pci_generic_config_write32: 108 callbacks suppressed
> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x4c may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x9c may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x88 may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x90 may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:02.0 offset 0x4 may corrupt adjacent RW1C bits
> igb 0002:04:00.1: removed PHC on enP2p4s0f1
> igb 0002:04:00.0: removed PHC on enP2p4s0f0
> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x4c may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x9c may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x88 may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x90 may corrupt adjacent RW1C bits
> pci_bus 0002:00: 2-byte config write to 0002:00:01.0 offset 0x4 may corrupt adjacent RW1C bits
> rcu: INFO: rcu_preempt self-detected stall on CPU
> SError Interrupt on CPU0, code 0xbf000002 -- SError
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc3-next-20190405-00027-gcd8110499e6f-dirty #42
> Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
> pstate: 20000085 (nzCv daIf -PAN -UAO)
> pc : tegra_pcie_isr+0x58/0x178 [pci_tegra]
> lr : tegra_pcie_isr+0x40/0x178 [pci_tegra]
> sp : ffff000010003da0
> x29: ffff000010003da0 x28: 0000000000000000
> x27: ffff8000f9e61000 x26: ffff000010fbf420
> x25: ffff000011427f93 x24: ffff8000fa600410
> x23: ffff00001129d000 x22: ffff00001129d000
> x21: ffff8000f18bf3c0 x20: 0000000000000070
> x19: 00000000ffffffff x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000
> x15: 0000000000000000 x14: ffff000008d40a48
> x13: ffff000008d40a30 x12: ffff000008d40a20
> x11: ffff000008d40a10 x10: ffff000008d40a00
> x9 : ffff000008d409e8 x8 : ffff000008d40ae8
> x7 : ffff000008d40ad0 x6 : ffff000010003e58
> x5 : ffff8000fac00248 x4 : 0000000000000000
> x3 : ffff000008d40b08 x2 : fffffffffffffff8
> x1 : ffff000008d3f4e8 x0 : 00000000ffffffff
> Kernel panic - not syncing: Asynchronous SError Interrupt
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.1.0-rc3-next-20190405-00027-gcd8110499e6f-dirty #42
> Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
> Call trace:
> dump_backtrace+0x0/0x158
> show_stack+0x14/0x20
> dump_stack+0xa8/0xcc
> panic+0x140/0x2f4
> nmi_panic+0x6c/0x70
> arm64_serror_panic+0x74/0x80
> __pte_error+0x0/0x28
> el1_error+0x84/0xf8
> tegra_pcie_isr+0x58/0x178 [pci_tegra]
> __handle_irq_event_percpu+0x70/0x198
> handle_irq_event_percpu+0x34/0x88
> handle_irq_event+0x48/0x78
> handle_fasteoi_irq+0xb4/0x190
> generic_handle_irq+0x24/0x38
> __handle_domain_irq+0x5c/0xb8
> gic_handle_irq+0x58/0xa8
> el1_irq+0xb8/0x180
> cpuidle_enter_state+0x138/0x358
> cpuidle_enter+0x18/0x20
> call_cpuidle+0x1c/0x48
> do_idle+0x230/0x2d0
> cpu_startup_entry+0x20/0x28
> rest_init+0xd4/0xe0
> arch_call_rest_init+0xc/0x14
> start_kernel+0x444/0x470
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> Acked-by: Thierry Reding <treding@nvidia.com>
> ---
> V6: No change
>
> V5:
> * Added blank line before block-style comment
>
> V4: No change
>
> V3:
> * Update the commit log and comment to reflect why this fix is required
> * MSI interrupt is not disabled
>
> V2: This is new patch in V2
>
> drivers/pci/controller/pci-tegra.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
> index bb3c0af9c830..0453bfb2726e 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -1622,6 +1622,15 @@ static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
> return 0;
> }
>
> +static void tegra_pcie_disable_interrupts(struct tegra_pcie *pcie)
> +{
> + u32 value;
> +
> + value = afi_readl(pcie, AFI_INTR_MASK);
> + value &= ~AFI_INTR_MASK_INT_MASK;
> + afi_writel(pcie, value, AFI_INTR_MASK);
> +}
> +
> static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
> u32 *xbar)
> {
> @@ -2467,6 +2476,12 @@ static int __maybe_unused tegra_pcie_pm_suspend(struct device *dev)
>
> tegra_pcie_disable_ports(pcie);
>
> + /*
> + * AFI_INTR is unmasked in tegra_pcie_enable_controller(), mask it to
> + * avoid unwanted interrupts raised by AFI after pex_rst is asserted.
> + */
> + tegra_pcie_disable_interrupts(pcie);
When do you re-enable it ? I assume it is enabled by default for
a reason, so if you disable on suspend you renable it on resume.
Please explain or I will drop this patch from the series.
Lorenzo
> +
> if (pcie->soc->program_uphy) {
> err = tegra_pcie_phy_power_off(pcie);
> if (err < 0)
> --
> 2.17.1
>
^ permalink raw reply
* Re: phosphor-ipmi-flash making progress!
From: Patrick Venture @ 2019-06-20 14:26 UTC (permalink / raw)
To: Neeraj Ladkani; +Cc: OpenBMC Maillist
In-Reply-To: <SN6PR2101MB0943F194BD7DF1868ADED4DDC8E40@SN6PR2101MB0943.namprd21.prod.outlook.com>
On Wed, Jun 19, 2019 at 11:23 PM Neeraj Ladkani <neladk@microsoft.com> wrote:
>
> What are in-band update methods for OpenBMC? I see this(phosphor-ipmi-flash) can take takes ~3 hours over IPMI. What is the solution for in-band update? what tools can be used?
It supports the LPC memory region interface available with the Aspeed
and Nuvoton BMCs. Then it doesn't take 3 hours. It also supports
using the aspeed pci-to-ahb bridge on Aspeed. It will probably
support Nuvoton's variation of that, but that's beyond my current
scoping. As far as tools, i don't entirely know what you mean. There
is a tool in phosphor-ipmi-flash for the host.
>
> Neeraj
>
> -----Original Message-----
> From: openbmc <openbmc-bounces+neladk=microsoft.com@lists.ozlabs.org> On Behalf Of Patrick Venture
> Sent: Wednesday, June 12, 2019 6:04 PM
> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: phosphor-ipmi-flash making progress!
>
> For those interested parties, phosphor-ipmi-flash which provides a variety of out-of-band mechanisms for updating the BMC in a fully-configurable manner is nearly ready for wide distribution.
>
> Currently supported: aspeed-p2a-ctrl (ipmipci), and inband (ipmibt)* Shortly supported: aspeed-lpc-ctrl (ipmilpc)
>
> *There is a bug in the transmit buffer size depending on whether it's over KCS versus actually BT since BT has a smaller buffer requirement.
>
> UBI Tarball updates aren't yet supported, but that's only a matter of someone writing an update handler. The firmware handler on the BMC can be extended easily to support a variety of verification and update mechanisms. The default behavior is to leverage a service for each of these things. One can implement whatever they really want for each service.
>
> The file sent to the BMC isn't required to have a signature file. One could simply skip sending the hash file and have a verification step that doesn't do anything special. So, it's very flexible.
>
> Here's some output:
>
> $ ./phosphor_ipmi_flash_tool --command update --interface ipmipci --image image-bmc --sig image-bmc.sig
>
> Sending over the firmware image.
> [0x1a03 0x2000]
> The bridge is enabled!
> Received address: 0x47ff0000
> Sending over the hash file.
> [0x1a03 0x2000]
> The bridge is enabled!
> Received address: 0x47ff0000
>
> Opening the verification file
> Committing to /flash/verify file to trigger service Calling stat on /flash/verify session to check status other running running success Returned success succeeded
>
> Opening the update file
> Committing to /flash/update file to trigger service Calling stat on /flash/update session to check status running Exception received: blob exception received: Received IPMI_CC: busy
>
> On the BMC:
> shutdown: reboot --timeout 90000000us --log-level 6 --log-target kmsg --log-color
> + awk '/oldroot|mnt/ { print $2 }'
> + sort -r
> + umount /oldroot/sys/kernel/debug
> + umount /oldroot/sys/fs/cgroup/unified
> + umount /oldroot/sys/fs/cgroup/systemd
> + umount /oldroot/sys/fs/cgroup
> + umount /oldroot/sys/fs/bpf
> + umount /oldroot/sys
> + umount /oldroot/proc
> + umount /oldroot/dev/shm
> + umount /oldroot/dev/pts
> + umount /oldroot/dev
> + umount /oldroot
> + umount /mnt/initramfs/rw
> + umount /mnt/initramfs/ro
> + umount /mnt
> + set +x
> Pinging watchdog with args -t 1 -T 5
> update: --clean-saved-files
> [ 8240.817801] jffs2: notice: (1171) jffs2_build_xattr_subsystem:
> complete building xattr subsystem, 17 of xdatum (15 unchecked, 1
> orphan) and 30 of xref (1 dead, 0 orphan) found.
> Updating bmc...
> Erasing block: 69/512 (13%)
>
> Given a BMC configuration:
> EXTRA_OECONF_append_quanta-q71l = " --enable-static-layout"
> EXTRA_OECONF_append_quanta-q71l = " --enable-pci-bridge"
> EXTRA_OECONF_append_quanta-q71l = " --enable-aspeed-p2a"
> EXTRA_OECONF_append_quanta-q71l = " --enable-reboot-update"
> EXTRA_OECONF_append_quanta-q71l = " MAPPED_ADDRESS=0x47FF0000"
>
>
> Patrick
^ permalink raw reply
* [GIT PULL] drm/imx: ipu-v3 image converter fixes
From: Philipp Zabel @ 2019-06-20 14:26 UTC (permalink / raw)
To: David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
Hi Dave, Daniel,
please consider merging these fixes for v5.2.
regards
Philipp
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the Git repository at:
git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2019-06-20
for you to fetch changes up to 912bbf7e9ca422099935dd69d3ff0fd62db24882:
gpu: ipu-v3: image-convert: Fix image downsize coefficients (2019-06-14 14:06:16 +0200)
----------------------------------------------------------------
drm/imx: ipu-v3 image converter fixes
This series fixes input buffer alignment and downsizer configuration
to adhere to IPU mem2mem CSC/scaler hardware restrictions in certain
downscaling ratios.
----------------------------------------------------------------
Steve Longerbeam (3):
gpu: ipu-v3: image-convert: Fix input bytesperline width/height align
gpu: ipu-v3: image-convert: Fix input bytesperline for packed formats
gpu: ipu-v3: image-convert: Fix image downsize coefficients
drivers/gpu/ipu-v3/ipu-image-convert.c | 40 +++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 13 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 5/5] drm/i915: Drop redundant aspec ratio prop value initialization
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Ilia Mirkin
In-Reply-To: <20190620142639.17518-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/display/intel_sdvo.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 6a4650b44ac6..f95f3db5ecb8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2809,7 +2809,6 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
intel_attach_colorspace_property(connector);
drm_connector_attach_content_type_property(connector);
- connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
drm_object_attach_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 5cb619613157..c471fcce59f8 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2624,7 +2624,6 @@ intel_sdvo_add_hdmi_properties(struct intel_sdvo *intel_sdvo,
intel_attach_broadcast_rgb_property(&connector->base.base);
}
intel_attach_aspect_ratio_property(&connector->base.base);
- connector->base.base.state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
static struct intel_sdvo_connector *intel_sdvo_connector_alloc(void)
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 4/5] drm/i915: Do not override mode's aspect ratio with the prop value NONE
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx
In-Reply-To: <20190620142639.17518-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.
Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++--
drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ebec69bbbfc..6a4650b44ac6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2394,8 +2394,9 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
return -EINVAL;
}
- /* Set user selected PAR to incoming mode's member */
- adjusted_mode->picture_aspect_ratio = conn_state->picture_aspect_ratio;
+ if (conn_state->picture_aspect_ratio)
+ adjusted_mode->picture_aspect_ratio =
+ conn_state->picture_aspect_ratio;
pipe_config->lane_count = 4;
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c b/drivers/gpu/drm/i915/display/intel_sdvo.c
index ceda03e5a3d4..5cb619613157 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -1321,9 +1321,9 @@ static int intel_sdvo_compute_config(struct intel_encoder *encoder,
if (IS_TV(intel_sdvo_connector))
i9xx_adjust_sdvo_tv_clock(pipe_config);
- /* Set user selected PAR to incoming mode's member */
- if (intel_sdvo_connector->is_hdmi)
- adjusted_mode->picture_aspect_ratio = conn_state->picture_aspect_ratio;
+ if (conn_state->picture_aspect_ratio)
+ adjusted_mode->picture_aspect_ratio =
+ conn_state->picture_aspect_ratio;
if (!intel_sdvo_compute_avi_infoframe(intel_sdvo,
pipe_config, conn_state)) {
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 3/5] drm: WARN on illegal aspect ratio when converting a mode to umode
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Ilia Mirkin
In-Reply-To: <20190620142639.17518-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
WARN if the incoming drm_display_mode has an illegal aspect ratio
when converting it to a user mode. This should never happen unless
the driver made a mistake and put an invalid value into the aspect
ratio.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/drm_modes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 847048dee048..be2ccd8eccfd 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1906,8 +1906,11 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
case HDMI_PICTURE_ASPECT_256_135:
out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
break;
- case HDMI_PICTURE_ASPECT_RESERVED:
default:
+ WARN(1, "Invalid aspect ratio (0%x) on mode\n",
+ in->picture_aspect_ratio);
+ /* fall through */
+ case HDMI_PICTURE_ASPECT_NONE:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
break;
}
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 2/5] drm: Do not accept garbage mode aspect ratio flags
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Ilia Mirkin
In-Reply-To: <20190620142639.17518-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Don't let userspace feed us any old garbage in the mode aspect ratio
flags.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/drm_modes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53acc6756ee0..847048dee048 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1977,9 +1977,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_256_135:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
break;
- default:
+ case DRM_MODE_FLAG_PIC_AR_NONE:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
+ default:
+ return -EINVAL;
}
out->status = drm_mode_validate_driver(dev, out);
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 1/5] drm: Do not use bitwise OR to set picure_aspect_ratio
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx
In-Reply-To: <20190620142639.17518-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR
to populate it.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/drm_modes.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 57e6408288c8..53acc6756ee0 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1966,16 +1966,16 @@ int drm_mode_convert_umode(struct drm_device *dev,
switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
case DRM_MODE_FLAG_PIC_AR_4_3:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
break;
case DRM_MODE_FLAG_PIC_AR_16_9:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
case DRM_MODE_FLAG_PIC_AR_64_27:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
break;
case DRM_MODE_FLAG_PIC_AR_256_135:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 0/5] drm: Aspect ratio fixes
From: Ville Syrjala @ 2019-06-20 14:26 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Ilia Mirkin
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Ilia pointed out some oddball crap in the i915 aspect ratio handling.
While looking at that I noticed a bunch of fail in the core as well.
This series aims to fix it all.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Ville Syrjälä (5):
drm: Do not use bitwise OR to set picure_aspect_ratio
drm: Do not accept garbage mode aspect ratio flags
drm: WARN on illegal aspect ratio when converting a mode to umode
drm/i915: Do not override mode's aspect ratio with the prop value NONE
drm/i915: Drop redundant aspec ratio prop value initialization
drivers/gpu/drm/drm_modes.c | 17 +++++++++++------
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +---
3 files changed, 14 insertions(+), 12 deletions(-)
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCHv2] cmake.bbclass: pass mandatory compiler flags through CMAKE_<LANG>_COMPILER_ARG1
From: Nikolai Merinov @ 2019-06-20 14:16 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
In-Reply-To: <75cc94f6-8e4c-68ff-3c65-a2b8f98e8842@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4751 bytes --]
Hi,
Updated patch for the current "master" branch is attached.
> have you also tried building SDK and see if these changes are reflected in SDK as well ?
I checked that the changes reflected in the Extensible SDK for the "core-image-sato" image of the poky.
Regards,
Nikolai
----- Original Message -----
From: "Khem Raj" <raj.khem@gmail.com>
To: "n merinov" <n.merinov@inango-systems.com>, "openembedded-core" <openembedded-core@lists.openembedded.org>
Sent: Tuesday, May 21, 2019 1:41:46 AM
Subject: Re: [OE-core] [PATCH] cmake.bbclass: pass mandatory compiler flags through CMAKE_<LANG>_COMPILER_ARG1
On 5/14/19 8:04 AM, Nikolai Merinov wrote:
> The CMake takes mandatory compiler arguments from the following variables:
> - CMAKE_SYSROOT -- path to sysroot that should be passed to compiler.
> - CMAKE_<LANG>_COMPILER_TARGET -- target architecture, used for compilers
> that supports several targets through command line options.
> e.g. "clang --target ${CMAKE_C_COMPILER_TARGET}".
> - CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN -- path to external toolchain,
> used for compilers that support build with external toolchain.
> e.g. "clang --gcc-toolchain ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}".
> - CMAKE_<LANG>_COMPILER_ARG1 -- other mandatory arguments to a compiler
> command.
>
> CMAKE_<LANG>_COMPILER_ARG1 is the most suitable variable to pass mandatory
> arguments, that belongs to CC variable with other build systems, to a
> compiler.
>
> Additionally usage of CMAKE_<LANG>_COMPILER_ARG1 instead of
> CMAKE_<LANG>_FLAGS reduce the risk that a variable can be overrided by
> CMakeLists.txt files.
> ---
> meta/classes/cmake.bbclass | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index d3f0d70847..4da4c00a09 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -27,27 +27,33 @@ python() {
> cc_list = d.getVar('CC').split()
> if cc_list[0] == 'ccache':
> d.setVar('OECMAKE_C_COMPILER', '%s %s' % (cc_list[0], cc_list[1]))
> + cc_arg1 = ' '.join(cc_list[2:])
> else:
> d.setVar('OECMAKE_C_COMPILER', cc_list[0])
> + cc_arg1 = ' '.join(cc_list[1:])
> + if not d.getVar('OECMAKE_C_COMPILER_ARG1'):
> + d.setVar('OECMAKE_C_COMPILER_ARG1', cc_arg1)
>
> if not d.getVar('OECMAKE_CXX_COMPILER'):
> cxx_list = d.getVar('CXX').split()
> if cxx_list[0] == 'ccache':
> d.setVar('OECMAKE_CXX_COMPILER', '%s %s' % (cxx_list[0], cxx_list[1]))
> + cxx_arg1 = ' '.join(cxx_list[2:])
> else:
> d.setVar('OECMAKE_CXX_COMPILER', cxx_list[0])
> + cxx_arg1 = ' '.join(cxx_list[1:])
> + if not d.getVar('OECMAKE_CXX_COMPILER_ARG1'):
> + d.setVar('OECMAKE_CXX_COMPILER_ARG1', cxx_arg1)
> }
> OECMAKE_AR ?= "${AR}"
>
> # Compiler flags
> -OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}"
> -OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS}"
> +OECMAKE_C_FLAGS ?= "${CFLAGS}"
> +OECMAKE_CXX_FLAGS ?= "${CXXFLAGS}"
> OECMAKE_C_FLAGS_RELEASE ?= "-DNDEBUG"
> OECMAKE_CXX_FLAGS_RELEASE ?= "-DNDEBUG"
> -OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}"
> -OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
> -CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> -CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> +OECMAKE_C_LINK_FLAGS ?= "${CPPFLAGS} ${LDFLAGS}"
> +OECMAKE_CXX_LINK_FLAGS ?= "${CXXFLAGS} ${LDFLAGS}"
>
> OECMAKE_RPATH ?= ""
> OECMAKE_PERLNATIVE_DIR ??= ""
> @@ -85,8 +91,11 @@ $cmake_crosscompiling
> set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 's/^\(Linux\).*/\1/'` )
> set( CMAKE_SYSTEM_PROCESSOR ${@map_target_arch_to_uname_arch(d.getVar('TARGET_ARCH'))} )
> set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
> +set( CMAKE_C_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
> set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
> +set( CMAKE_CXX_COMPILER_ARG1 "${OECMAKE_CXX_COMPILER_ARG1}" )
> set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
> +set( CMAKE_ASM_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
> set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
> set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
> set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
>
these changes look ok, have you also tried building SDK and see if these
changes are reflected in SDK as well ?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-cmake.bbclass-pass-mandatory-compiler-flags-through-.patch --]
[-- Type: text/x-patch; name=0001-cmake.bbclass-pass-mandatory-compiler-flags-through-.patch, Size: 4086 bytes --]
From 07dcf522cb4cadf211e76cd66f1897f6e22ca6e1 Mon Sep 17 00:00:00 2001
From: Nikolai Merinov <n.merinov@inango-systems.com>
Date: Thu, 20 Jun 2019 14:15:14 +0500
Subject: [PATCH] cmake.bbclass: pass mandatory compiler flags through
CMAKE_<LANG>_COMPILER_ARG1
The CMake takes mandatory compiler arguments from the following variables:
- CMAKE_SYSROOT -- path to sysroot that should be passed to compiler.
- CMAKE_<LANG>_COMPILER_TARGET -- target architecture, used for compilers
that supports several targets through command line options.
e.g. "clang --target ${CMAKE_C_COMPILER_TARGET}".
- CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN -- path to external toolchain,
used for compilers that support build with external toolchain.
e.g. "clang --gcc-toolchain ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}".
- CMAKE_<LANG>_COMPILER_ARG1 -- other mandatory arguments to a compiler
command.
CMAKE_<LANG>_COMPILER_ARG1 is the most suitable variable to pass mandatory
arguments, that belongs to CC variable with other build systems, to a
compiler.
Additionally usage of CMAKE_<LANG>_COMPILER_ARG1 instead of
CMAKE_<LANG>_FLAGS reduce the risk that a variable can be overrided by
CMakeLists.txt files.
---
meta/classes/cmake.bbclass | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index f80a7e2f1d..034735bc13 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -28,26 +28,34 @@ python() {
if cc_list[0] == 'ccache':
d.setVar('OECMAKE_C_COMPILER_LAUNCHER', cc_list[0])
d.setVar('OECMAKE_C_COMPILER', cc_list[1])
+ cc_arg1 = ' '.join(cc_list[2:])
else:
d.setVar('OECMAKE_C_COMPILER', cc_list[0])
+ cc_arg1 = ' '.join(cc_list[1:])
+ if not d.getVar('OECMAKE_C_COMPILER_ARG1'):
+ d.setVar('OECMAKE_C_COMPILER_ARG1', cc_arg1)
if not d.getVar('OECMAKE_CXX_COMPILER'):
cxx_list = d.getVar('CXX').split()
if cxx_list[0] == 'ccache':
d.setVar('OECMAKE_CXX_COMPILER_LAUNCHER', cxx_list[0])
d.setVar('OECMAKE_CXX_COMPILER', cxx_list[1])
+ cxx_arg1 = ' '.join(cxx_list[2:])
else:
d.setVar('OECMAKE_CXX_COMPILER', cxx_list[0])
+ cxx_arg1 = ' '.join(cxx_list[1:])
+ if not d.getVar('OECMAKE_CXX_COMPILER_ARG1'):
+ d.setVar('OECMAKE_CXX_COMPILER_ARG1', cxx_arg1)
}
OECMAKE_AR ?= "${AR}"
# Compiler flags
-OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}"
-OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS}"
+OECMAKE_C_FLAGS ?= "${CFLAGS}"
+OECMAKE_CXX_FLAGS ?= "${CXXFLAGS}"
OECMAKE_C_FLAGS_RELEASE ?= "-DNDEBUG"
OECMAKE_CXX_FLAGS_RELEASE ?= "-DNDEBUG"
-OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}"
-OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
+OECMAKE_C_LINK_FLAGS ?= "${CPPFLAGS} ${LDFLAGS}"
+OECMAKE_CXX_LINK_FLAGS ?= "${CPPFLAGS} ${LDFLAGS}"
CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
@@ -90,10 +98,13 @@ $cmake_crosscompiling
set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 's/^\(Linux\).*/\1/'` )
set( CMAKE_SYSTEM_PROCESSOR ${@map_target_arch_to_uname_arch(d.getVar('TARGET_ARCH'))} )
set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
+set( CMAKE_C_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
+set( CMAKE_CXX_COMPILER_ARG1 "${OECMAKE_CXX_COMPILER_ARG1}" )
set( CMAKE_C_COMPILER_LAUNCHER ${OECMAKE_C_COMPILER_LAUNCHER} )
set( CMAKE_CXX_COMPILER_LAUNCHER ${OECMAKE_CXX_COMPILER_LAUNCHER} )
set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
+set( CMAKE_ASM_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS
From: Masahiro Yamada @ 2019-06-20 14:23 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Michal Marek, Linux Kbuild mailing list,
Linux Kernel Mailing List, clang-built-linux, Nick Desaulniers,
Peter Smith
In-Reply-To: <20190611184331.44242-1-natechancellor@gmail.com>
On Wed, Jun 12, 2019 at 3:43 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
> drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
> a GCC only option so clang rightfully complains:
>
> warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
>
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
>
> However, by default, this is merely a warning so the build happily goes
> on with a slew of these warnings in the process.
>
> Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
> support clang") worked around this behavior in cc-option by adding
> -Werror so that unknown flags cause an error. However, this all happens
> silently and when an unknown flag is added to the build unconditionally
> like -Wno-psabi, cc-option will always fail because there is always an
> unknown flag in the list of flags. This manifested as link time failures
> in the arm64 libstub because -fno-stack-protector didn't get added to
> KBUILD_CFLAGS.
>
> To avoid these weird cryptic failures in the future, make clang behave
> like gcc and immediately error when it encounters an unknown flag by
> adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
> unconditionally for clang because it is supported by at least 3.0.0,
> according to godbolt [1] and 4.0.0, according to its documentation [2],
> which is far earlier than we typically support.
>
> [1]: https://godbolt.org/z/7F7rm3
> [2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/511
> Link: https://github.com/ClangBuiltLinux/linux/issues/517
> Suggested-by: Peter Smith <peter.smith@linaro.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
Applied to linux-kbuild.
Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next v6 08/11] ipv6: Dump route exceptions if requested
From: David Ahern @ 2019-06-20 14:24 UTC (permalink / raw)
To: Stefano Brivio, David Miller
Cc: Jianlin Shi, Wei Wang, Martin KaFai Lau, Eric Dumazet,
Matti Vaittinen, netdev
In-Reply-To: <13c143591fe786dc452ec6c99b8ff1414ef8929d.1560987611.git.sbrivio@redhat.com>
On 6/19/19 5:59 PM, Stefano Brivio wrote:
> + if (filter->dump_exceptions) {
> + struct fib6_nh_exception_dump_walker w = { .dump = arg,
> + .rt = rt,
> + .flags = flags,
> + .skip = skip,
> + .count = 0 };
> + int err;
> +
> + if (rt->nh) {
> + err = nexthop_for_each_fib6_nh(rt->nh,
> + rt6_nh_dump_exceptions,
> + &w);
much like ipv4, the skb can fill in the middle of a fib6_nh bucket, so
you need to track which nexthop is in progress.
^ permalink raw reply
* Re: [PATCH v2] mm, memcg: Add a memcg_slabinfo debugfs file
From: Waiman Long @ 2019-06-20 14:23 UTC (permalink / raw)
To: Shakeel Butt
Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
Andrew Morton, Linux MM, LKML, Michal Hocko, Roman Gushchin,
Johannes Weiner, Vladimir Davydov
In-Reply-To: <CALvZod7pdOx0a1v4oX5-7ZfCykM8iwRwPkW-+gbO1B4+j1SXqw@mail.gmail.com>
On 6/19/19 7:48 PM, Shakeel Butt wrote:
> Hi Waiman,
>
> On Wed, Jun 19, 2019 at 10:16 AM Waiman Long <longman@redhat.com> wrote:
>> There are concerns about memory leaks from extensive use of memory
>> cgroups as each memory cgroup creates its own set of kmem caches. There
>> is a possiblity that the memcg kmem caches may remain even after the
>> memory cgroups have been offlined. Therefore, it will be useful to show
>> the status of each of memcg kmem caches.
>>
>> This patch introduces a new <debugfs>/memcg_slabinfo file which is
>> somewhat similar to /proc/slabinfo in format, but lists only information
>> about kmem caches that have child memcg kmem caches. Information
>> available in /proc/slabinfo are not repeated in memcg_slabinfo.
>>
>> A portion of a sample output of the file was:
>>
>> # <name> <css_id[:dead]> <active_objs> <num_objs> <active_slabs> <num_slabs>
>> rpc_inode_cache root 13 51 1 1
>> rpc_inode_cache 48 0 0 0 0
>> fat_inode_cache root 1 45 1 1
>> fat_inode_cache 41 2 45 1 1
>> xfs_inode root 770 816 24 24
>> xfs_inode 92 22 34 1 1
>> xfs_inode 88:dead 1 34 1 1
>> xfs_inode 89:dead 23 34 1 1
>> xfs_inode 85 4 34 1 1
>> xfs_inode 84 9 34 1 1
>>
>> The css id of the memcg is also listed. If a memcg is not online,
>> the tag ":dead" will be attached as shown above.
>>
>> Suggested-by: Shakeel Butt <shakeelb@google.com>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> mm/slab_common.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 58251ba63e4a..2bca1558a722 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -17,6 +17,7 @@
>> #include <linux/uaccess.h>
>> #include <linux/seq_file.h>
>> #include <linux/proc_fs.h>
>> +#include <linux/debugfs.h>
>> #include <asm/cacheflush.h>
>> #include <asm/tlbflush.h>
>> #include <asm/page.h>
>> @@ -1498,6 +1499,62 @@ static int __init slab_proc_init(void)
>> return 0;
>> }
>> module_init(slab_proc_init);
>> +
>> +#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_MEMCG_KMEM)
>> +/*
>> + * Display information about kmem caches that have child memcg caches.
>> + */
>> +static int memcg_slabinfo_show(struct seq_file *m, void *unused)
>> +{
>> + struct kmem_cache *s, *c;
>> + struct slabinfo sinfo;
>> +
>> + mutex_lock(&slab_mutex);
> On large machines there can be thousands of memcgs and potentially
> each memcg can have hundreds of kmem caches. So, the slab_mutex can be
> held for a very long time.
But that is also what /proc/slabinfo does by doing mutex_lock() at
slab_start() and mutex_unlock() at slab_stop(). So the same problem will
happen when /proc/slabinfo is being read.
When you are in a situation that reading /proc/slabinfo take a long time
because of the large number of memcg's, the system is in some kind of
trouble anyway. I am saying that we should not improve the scalability
of this patch. It is just that some nasty race conditions may pop up if
we release the lock and re-acquire it latter. That will greatly
complicate the code to handle all those edge cases.
> Our internal implementation traverses the memcg tree and then
> traverses 'memcg->kmem_caches' within the slab_mutex (and
> cond_resched() after unlock).
For cgroup v1, the setting of the CONFIG_SLUB_DEBUG option will allow
you to iterate and display slabinfo just for that particular memcg. I am
thinking of extending the debug controller to do similar thing for
cgroup v2.
>> + seq_puts(m, "# <name> <css_id[:dead]> <active_objs> <num_objs>");
>> + seq_puts(m, " <active_slabs> <num_slabs>\n");
>> + list_for_each_entry(s, &slab_root_caches, root_caches_node) {
>> + /*
>> + * Skip kmem caches that don't have any memcg children.
>> + */
>> + if (list_empty(&s->memcg_params.children))
>> + continue;
>> +
>> + memset(&sinfo, 0, sizeof(sinfo));
>> + get_slabinfo(s, &sinfo);
>> + seq_printf(m, "%-17s root %6lu %6lu %6lu %6lu\n",
>> + cache_name(s), sinfo.active_objs, sinfo.num_objs,
>> + sinfo.active_slabs, sinfo.num_slabs);
>> +
>> + for_each_memcg_cache(c, s) {
>> + struct cgroup_subsys_state *css;
>> + char *dead = "";
>> +
>> + css = &c->memcg_params.memcg->css;
>> + if (!(css->flags & CSS_ONLINE))
>> + dead = ":dead";
> Please note that Roman's kmem cache reparenting patch series have made
> kmem caches of zombie memcgs a bit tricky. On memcg offlining the
> memcg kmem caches are reparented and the css->id can get recycled. So,
> we want to know that the a kmem cache is reparented and which memcg it
> belonged to initially. Determining if a kmem cache is reparented, we
> can store a flag on the kmem cache and for the previous memcg we can
> use fhandle. However to not make this more complicated, for now, we
> can just have the info that the kmem cache was reparented i.e. belongs
> to an offlined memcg.
I need to play with Roman's kmem cache reparenting patch a bit more to
see how to properly recognize a reparent'ed kmem cache. What I have
noticed is that the dead kmem caches that I saw at boot up were gone
after applying his patch. So that is a good thing.
For now, I think the current patch is good enough for its purpose. I may
send follow-up if I see something that can be improved.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: Neil Horman @ 2019-06-20 14:23 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Matteo Croce, David S. Miller
In-Reply-To: <CA+FuTSe=kJSSvcYwCE9-omRF5Snd9AyesZac61PYyAHDStPt=A@mail.gmail.com>
On Thu, Jun 20, 2019 at 09:41:30AM -0400, Willem de Bruijn wrote:
> On Wed, Jun 19, 2019 at 4:26 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > When an application is run that:
> > a) Sets its scheduler to be SCHED_FIFO
> > and
> > b) Opens a memory mapped AF_PACKET socket, and sends frames with the
> > MSG_DONTWAIT flag cleared, its possible for the application to hang
> > forever in the kernel. This occurs because when waiting, the code in
> > tpacket_snd calls schedule, which under normal circumstances allows
> > other tasks to run, including ksoftirqd, which in some cases is
> > responsible for freeing the transmitted skb (which in AF_PACKET calls a
> > destructor that flips the status bit of the transmitted frame back to
> > available, allowing the transmitting task to complete).
> >
> > However, when the calling application is SCHED_FIFO, its priority is
> > such that the schedule call immediately places the task back on the cpu,
> > preventing ksoftirqd from freeing the skb, which in turn prevents the
> > transmitting task from detecting that the transmission is complete.
> >
> > We can fix this by converting the schedule call to a completion
> > mechanism. By using a completion queue, we force the calling task, when
> > it detects there are no more frames to send, to schedule itself off the
> > cpu until such time as the last transmitted skb is freed, allowing
> > forward progress to be made.
> >
> > Tested by myself and the reporter, with good results
> >
> > Appies to the net tree
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > Reported-by: Matteo Croce <mcroce@redhat.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > ---
>
> This is a complex change for a narrow configuration. Isn't a
> SCHED_FIFO process preempting ksoftirqd a potential problem for other
> networking workloads as well? And the right configuration to always
> increase ksoftirqd priority when increasing another process's
> priority? Also, even when ksoftirqd kicks in, isn't some progress
> still made on the local_bh_enable reached from schedule()?
>
A few questions here to answer:
Regarding other protocols having this problem, thats not the case, because non
packet sockets honor the SK_SNDTIMEO option here (i.e. they sleep for a period
of time specified by the SNDTIMEO option if MSG_DONTWAIT isn't set. We could
certainly do that, but the current implementation doesn't (opting instead to
wait indefinately until the respective packet(s) have transmitted or errored
out), and I wanted to maintain that behavior. If there is consensus that packet
sockets should honor SNDTIMEO, then I can certainly do that.
As for progress made by calling local_bh_enable, My read of the code doesn't
have the scheduler calling local_bh_enable at all. Instead schedule uses
preempt_disable/preempt_enable_no_resched() to gain exlcusive access to the cpu,
which ignores pending softirqs on re-enablement. Perhaps that needs to change,
but I'm averse to making scheduler changes for this (the aforementioned concern
about complex changes for a narrow use case)
Regarding raising the priority of ksoftirqd, that could be a solution, but the
priority would need to be raised to a high priority SCHED_FIFO parameter, and
that gets back to making complex changes for a narrow problem domain
As for the comlexity of the of the solution, I think this is, given your
comments the least complex and intrusive change to solve the given problem. We
need to find a way to force the calling task off the cpu while the asynchronous
operations in the transmit path complete, and we can do that this way, or by
honoring SK_SNDTIMEO. I'm fine with doing the latter, but I didn't want to
alter the current protocol behavior without consensus on that.
Regards
Neil
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] doc/cryptodev: clarify that full xform struct should be zeroed before use
From: Akhil Goyal @ 2019-06-20 14:23 UTC (permalink / raw)
To: Trahe, Fiona, dev@dpdk.org
Cc: De Lara Guarch, Pablo, Doherty, Declan, Zhang, Roy Fan,
jerinj@marvell.com, Nicolau, Radu
In-Reply-To: <348A99DA5F5B7549AA880327E580B43589768C28@IRSMSX101.ger.corp.intel.com>
Hi Fiona,
>
> Hi Akhil, etc,
> Is a deprecation notice necessary for this patch?
> If this patch is accepted I will send a follow-up patchset zeroing the xforms in
> crypto apps.
> Fiona
>
Sorry for late reply.
I don't think this patch need deprecation notice.
> > -----Original Message-----
> > From: Trahe, Fiona
> > Sent: Wednesday, May 15, 2019 5:37 PM
> > To: dev@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; akhil.goyal@nxp.com; De Lara
> Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Doherty, Declan
> <declan.doherty@intel.com>; Zhang, Roy Fan
> > <roy.fan.zhang@intel.com>; jerinj@marvell.com; Nicolau, Radu
> <radu.nicolau@intel.com>
> > Subject: [PATCH] doc/cryptodev: clarify that full xform struct should be zeroed
> before use
> >
> > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > ---
> > doc/guides/prog_guide/cryptodev_lib.rst | 10 ++++++++--
> > 1 files changed, 8 insertions(+), 2 deletions(-)
> >
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
^ permalink raw reply
* Re: [PATCH] ath11k: fetch and report DCM and RU stats from ppdu stats
From: Kalle Valo @ 2019-06-20 14:23 UTC (permalink / raw)
To: Pradeep Kumar Chitrapu; +Cc: ath11k
In-Reply-To: <1560872506-21217-1-git-send-email-pradeepc@codeaurora.org>
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> writes:
> HE DCM and RU allocation info is reported out of bound data path
> by firmware in ppdu stats. These are reported to mac80211 using
> sta_statistics() api.
>
> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
[...]
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -1093,7 +1093,7 @@ static u32 ath11k_bw_to_mac80211_bwflags(u8 bw)
> struct ieee80211_chanctx_conf *conf = NULL;
> struct ath11k_per_peer_tx_stats *peer_stats = &ar->peer_tx_stats;
> int ret;
> - u8 flags, mcs, nss, bw, sgi, rate_idx = 0;
> + u8 flags, mcs, nss, bw, sgi, dcm, rate_idx = 0;
> u32 succ_bytes = 0;
> u16 rate = 0, succ_pkts = 0;
> bool is_ampdu = false;
> @@ -1127,12 +1127,17 @@ static u32 ath11k_bw_to_mac80211_bwflags(u8 bw)
> * Firmare rate's control to be skipped for this?
> */
>
> - if (flags == WMI_RATE_PREAMBLE_VHT && mcs > 9) {
> + if (flags == WMI_RATE_PREAMBLE_HE && mcs > ATH11K_HE_MCS_MAX) {
> + ath11k_warn(ab, "Invalid HE mcs %hhd peer stats", mcs);
> + return;
> + }
> +
> + if (flags == WMI_RATE_PREAMBLE_VHT && mcs > ATH11K_VHT_MCS_MAX) {
> ath11k_warn(ab, "Invalid VHT mcs %hhd peer stats", mcs);
> return;
> }
>
> - if (flags == WMI_RATE_PREAMBLE_HT && (mcs > 7 || nss < 1)) {
> + if (flags == WMI_RATE_PREAMBLE_HT && (mcs > ATH11K_HT_MCS_MAX || nss < 1)) {
> ath11k_warn(ab, "Invalid HT mcs %hhd nss %hhd peer stats",
> mcs, nss);
> return;
> @@ -1201,6 +1206,12 @@ static u32 ath11k_bw_to_mac80211_bwflags(u8 bw)
> IEEE80211_TX_RC_SHORT_GI;
> }
> break;
> + case WMI_RATE_PREAMBLE_HE:
> + arsta->txrate.he_dcm = dcm;
This causes a new warning:
drivers/net/wireless/ath/ath11k/dp_rx.c:1159:24: warning: 'dcm' may be used uninitialized in this function [-Wmaybe-uninitialized]
Looks valid warning to me. How is this supposed to work, I don't see you
assigning to dcm anywhere?
--
Kalle Valo
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ 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.