* Re: linux-next: build failure after merge of the netfilter-next tree
From: Stephen Rothwell @ 2019-06-20 14:16 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: NetFilter, Linux Next Mailing List, Linux Kernel Mailing List,
Fernando Fernandez Mancera
In-Reply-To: <20190620135703.aiv62n6fhzf6wjwv@salvia>
[-- Attachment #1: Type: text/plain, Size: 284 bytes --]
Hi Pablo,
On Thu, 20 Jun 2019 15:57:03 +0200 Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git/commit/?id=8527fa6cc68a489f735823e61b31ec6cb266274a
Good timing :-)
Thanks.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RESEND 5.1-stable PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush
From: Greg KH @ 2019-06-20 14:16 UTC (permalink / raw)
To: Yang Shi
Cc: akpm, aneesh.kumar, jstancek, mgorman, minchan, namit, npiggin,
peterz, will.deacon, stable, linux-mm, linux-kernel
In-Reply-To: <1560805037-35324-1-git-send-email-yang.shi@linux.alibaba.com>
On Tue, Jun 18, 2019 at 04:57:17AM +0800, Yang Shi wrote:
> commit 7a30df49f63ad92318ddf1f7498d1129a77dd4bd upstream
THanks for the backport, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v6 06/11] ipv6/route: Don't match on fc_nh_id if not set in ip6_route_del()
From: David Ahern @ 2019-06-20 14:16 UTC (permalink / raw)
To: Stefano Brivio, David Miller
Cc: Jianlin Shi, Wei Wang, Martin KaFai Lau, Eric Dumazet,
Matti Vaittinen, netdev
In-Reply-To: <18a49a3a5d0274df90f059f37d3601abd0bac879.1560987611.git.sbrivio@redhat.com>
On 6/19/19 5:59 PM, Stefano Brivio wrote:
> If fc_nh_id isn't set, we shouldn't try to match against it. This
> actually matters just for the RTF_CACHE case below (where this is
> already handled): if iproute2 gets a route exception and tries to
> delete it, it won't reference its fc_nh_id, even if a nexthop
> object might be associated to the originating route.
>
> Fixes: 5b98324ebe29 ("ipv6: Allow routes to use nexthop objects")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> v6: New patch
>
> net/ipv6/route.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Thanks for catching that.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 4/4] nvme: add support weighted round robin queue
From: Minwoo Im @ 2019-06-20 14:16 UTC (permalink / raw)
To: Weiping Zhang
Cc: axboe, tj, hch, bvanassche, linux-block, cgroups, linux-nvme,
Javier González
In-Reply-To: <0b0fa12a337f97a8cc878b58673b3eb619539174.1560679439.git.zhangweiping@didiglobal.com>
> -static int write_queues;
> -module_param_cb(write_queues, &queue_count_ops, &write_queues, 0644);
> -MODULE_PARM_DESC(write_queues,
> - "Number of queues to use for writes. If not set, reads and writes "
> +static int read_queues;
> +module_param_cb(read_queues, &queue_count_ops, &read_queues, 0644);
> +MODULE_PARM_DESC(read_queues,
> + "Number of queues to use for reads. If not set, reads and writes "
> "will share a queue set.");
Before starting my review for this, I'd like to talk about this part
first. It would be better if you can split this change from this commit
into a new one because it just replaced the write_queues with
read_queues which is directly mapped to HCTX_TYPE_READ. This change
might not be critical for the WRR implementation.
>
> static int poll_queues = 0;
> module_param_cb(poll_queues, &queue_count_ops, &poll_queues, 0644);
> MODULE_PARM_DESC(poll_queues, "Number of queues to use for polled IO.");
>
> +static int wrr_high_queues = 0;
Nitpick here: maybe we don't need to 0-initialize static variables
explicitly.
> +module_param_cb(wrr_high_queues, &queue_count_ops, &wrr_high_queues, 0644);
> +MODULE_PARM_DESC(wrr_high_queues, "Number of queues to use for WRR high.");
> +
> +static int wrr_medium_queues = 0;
> +module_param_cb(wrr_medium_queues, &queue_count_ops, &wrr_medium_queues, 0644);
> +MODULE_PARM_DESC(wrr_medium_queues, "Number of queues to use for WRR medium.");
> +
> +static int wrr_low_queues = 0;
> +module_param_cb(wrr_low_queues, &queue_count_ops, &wrr_low_queues, 0644);
> +MODULE_PARM_DESC(wrr_low_queues, "Number of queues to use for WRR low.");
> +
> struct nvme_dev;
> struct nvme_queue;
>
> @@ -226,9 +238,17 @@ struct nvme_iod {
> struct scatterlist *sg;
> };
>
> +static inline bool nvme_is_enable_wrr(struct nvme_dev *dev)
> +{
> + return dev->io_queues[HCTX_TYPE_WRR_LOW] +
> + dev->io_queues[HCTX_TYPE_WRR_MEDIUM] +
> + dev->io_queues[HCTX_TYPE_WRR_HIGH] > 0;
> +}
It looks like that it might be confused with AMS(Arbitration Mechanism
Selected) in CC or CAP? If it meant how many irqs for the sets were
allocated, then can we have this function with another name like:
nvme_is_wrr_allocated or something indicating the irqsets
> +
> static unsigned int max_io_queues(void)
> {
> - return num_possible_cpus() + write_queues + poll_queues;
> + return num_possible_cpus() + read_queues + poll_queues +
> + wrr_high_queues + wrr_medium_queues + wrr_low_queues;
> }
>
> static unsigned int max_queue_count(void)
> @@ -1534,11 +1558,46 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, u16 qid)
> wmb(); /* ensure the first interrupt sees the initialization */
> }
>
> -static int nvme_create_queue(struct nvme_queue *nvmeq, int qid, bool polled)
> +static int nvme_create_queue(struct nvme_queue *nvmeq, int qid)
> {
> struct nvme_dev *dev = nvmeq->dev;
> - int result;
> + int start, end, result, wrr;
> + bool polled = false;
> u16 vector = 0;
> + enum hctx_type type;
> +
> + /* 0 for admain queue, io queue index >= 1 */
> + start = 1;
> + /* get hardware context type base on qid */
> + for (type = HCTX_TYPE_DEFAULT; type < HCTX_MAX_TYPES; type++) {
> + end = start + dev->io_queues[type] - 1;
> + if (qid >= start && qid <= end)
> + break;
> + start = end + 1;
> + }
> +
> + if (nvme_is_enable_wrr(dev)) {
I think we need to check not only the irqset allocations, but also if the
device is really supports WRR or not.
> + /* set read,poll,default to medium by default */
> + switch (type) {
> + case HCTX_TYPE_POLL:
> + polled = true;
Question: Is poll-queue not avilable to be used in case of !WRR?
> + case HCTX_TYPE_DEFAULT:
> + case HCTX_TYPE_READ:
> + case HCTX_TYPE_WRR_MEDIUM:
> + wrr = NVME_SQ_PRIO_MEDIUM;
Also it seems like it could be named like flags because it will show the
SQ priority. What do you think?
> + break;
> + case HCTX_TYPE_WRR_LOW:
> + wrr = NVME_SQ_PRIO_LOW;
> + break;
> + case HCTX_TYPE_WRR_HIGH:
> + wrr = NVME_SQ_PRIO_HIGH;
> + break;
> + default:
> + return -EINVAL;
> + }
> + } else {
> + wrr = 0;
Would it be different with the following value ?
NVME_SQ_PRIO_URGENT = (0 << 1)
If it means no WRR, then can it be avoided the value which is already
defined ?
> + }
>
> clear_bit(NVMEQ_DELETE_ERROR, &nvmeq->flags);
>
> @@ -2028,35 +2079,73 @@ static int nvme_setup_host_mem(struct nvme_dev *dev)
> static void nvme_calc_irq_sets(struct irq_affinity *affd, unsigned int nrirqs)
> {
> struct nvme_dev *dev = affd->priv;
> - unsigned int nr_read_queues;
> + unsigned int nr_total, nr, nr_read, nr_default;
> + unsigned int nr_wrr_high, nr_wrr_medium, nr_wrr_low;
> + unsigned int nr_sets;
>
> /*
> * If there is no interupt available for queues, ensure that
> * the default queue is set to 1. The affinity set size is
> * also set to one, but the irq core ignores it for this case.
> - *
> - * If only one interrupt is available or 'write_queue' == 0, combine
> - * write and read queues.
> - *
> - * If 'write_queues' > 0, ensure it leaves room for at least one read
> - * queue.
> */
> - if (!nrirqs) {
> + if (!nrirqs)
> nrirqs = 1;
> - nr_read_queues = 0;
> - } else if (nrirqs == 1 || !write_queues) {
> - nr_read_queues = 0;
> - } else if (write_queues >= nrirqs) {
> - nr_read_queues = 1;
> - } else {
> - nr_read_queues = nrirqs - write_queues;
> - }
>
> - dev->io_queues[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> - affd->set_size[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> - dev->io_queues[HCTX_TYPE_READ] = nr_read_queues;
> - affd->set_size[HCTX_TYPE_READ] = nr_read_queues;
> - affd->nr_sets = nr_read_queues ? 2 : 1;
> + nr_total = nrirqs;
> +
> + nr_read = nr_wrr_high = nr_wrr_medium = nr_wrr_low = 0;
> +
> + /* set default to 1, add all the rest queue to default at last */
> + nr = nr_default = 1;
> + nr_sets = 1;
> +
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* read queues */
> + nr_sets++;
> + nr_read = nr = read_queues > nr_total ? nr_total : read_queues;
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr low queues */
> + nr_sets++;
> + nr_wrr_low = nr = wrr_low_queues > nr_total ? nr_total : wrr_low_queues;
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr medium queues */
> + nr_sets++;
> + nr_wrr_medium = nr = wrr_medium_queues > nr_total ? nr_total : wrr_medium_queues;
It looks like exceeded 80 chracters here.
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr high queues */
> + nr_sets++;
> + nr_wrr_high = nr = wrr_high_queues > nr_total ? nr_total : wrr_high_queues;
> + nr_wrr_high = nr = wrr_high_queues > nr_total ? nr_total : wrr_high_queues;
Here also.
If I misunderstood something here, please feel free to let me know.
Thanks,
^ permalink raw reply
* [PATCH v2 4/4] nvme: add support weighted round robin queue
From: Minwoo Im @ 2019-06-20 14:16 UTC (permalink / raw)
In-Reply-To: <0b0fa12a337f97a8cc878b58673b3eb619539174.1560679439.git.zhangweiping@didiglobal.com>
> -static int write_queues;
> -module_param_cb(write_queues, &queue_count_ops, &write_queues, 0644);
> -MODULE_PARM_DESC(write_queues,
> - "Number of queues to use for writes. If not set, reads and writes "
> +static int read_queues;
> +module_param_cb(read_queues, &queue_count_ops, &read_queues, 0644);
> +MODULE_PARM_DESC(read_queues,
> + "Number of queues to use for reads. If not set, reads and writes "
> "will share a queue set.");
Before starting my review for this, I'd like to talk about this part
first. It would be better if you can split this change from this commit
into a new one because it just replaced the write_queues with
read_queues which is directly mapped to HCTX_TYPE_READ. This change
might not be critical for the WRR implementation.
>
> static int poll_queues = 0;
> module_param_cb(poll_queues, &queue_count_ops, &poll_queues, 0644);
> MODULE_PARM_DESC(poll_queues, "Number of queues to use for polled IO.");
>
> +static int wrr_high_queues = 0;
Nitpick here: maybe we don't need to 0-initialize static variables
explicitly.
> +module_param_cb(wrr_high_queues, &queue_count_ops, &wrr_high_queues, 0644);
> +MODULE_PARM_DESC(wrr_high_queues, "Number of queues to use for WRR high.");
> +
> +static int wrr_medium_queues = 0;
> +module_param_cb(wrr_medium_queues, &queue_count_ops, &wrr_medium_queues, 0644);
> +MODULE_PARM_DESC(wrr_medium_queues, "Number of queues to use for WRR medium.");
> +
> +static int wrr_low_queues = 0;
> +module_param_cb(wrr_low_queues, &queue_count_ops, &wrr_low_queues, 0644);
> +MODULE_PARM_DESC(wrr_low_queues, "Number of queues to use for WRR low.");
> +
> struct nvme_dev;
> struct nvme_queue;
>
> @@ -226,9 +238,17 @@ struct nvme_iod {
> struct scatterlist *sg;
> };
>
> +static inline bool nvme_is_enable_wrr(struct nvme_dev *dev)
> +{
> + return dev->io_queues[HCTX_TYPE_WRR_LOW] +
> + dev->io_queues[HCTX_TYPE_WRR_MEDIUM] +
> + dev->io_queues[HCTX_TYPE_WRR_HIGH] > 0;
> +}
It looks like that it might be confused with AMS(Arbitration Mechanism
Selected) in CC or CAP? If it meant how many irqs for the sets were
allocated, then can we have this function with another name like:
nvme_is_wrr_allocated or something indicating the irqsets
> +
> static unsigned int max_io_queues(void)
> {
> - return num_possible_cpus() + write_queues + poll_queues;
> + return num_possible_cpus() + read_queues + poll_queues +
> + wrr_high_queues + wrr_medium_queues + wrr_low_queues;
> }
>
> static unsigned int max_queue_count(void)
> @@ -1534,11 +1558,46 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, u16 qid)
> wmb(); /* ensure the first interrupt sees the initialization */
> }
>
> -static int nvme_create_queue(struct nvme_queue *nvmeq, int qid, bool polled)
> +static int nvme_create_queue(struct nvme_queue *nvmeq, int qid)
> {
> struct nvme_dev *dev = nvmeq->dev;
> - int result;
> + int start, end, result, wrr;
> + bool polled = false;
> u16 vector = 0;
> + enum hctx_type type;
> +
> + /* 0 for admain queue, io queue index >= 1 */
> + start = 1;
> + /* get hardware context type base on qid */
> + for (type = HCTX_TYPE_DEFAULT; type < HCTX_MAX_TYPES; type++) {
> + end = start + dev->io_queues[type] - 1;
> + if (qid >= start && qid <= end)
> + break;
> + start = end + 1;
> + }
> +
> + if (nvme_is_enable_wrr(dev)) {
I think we need to check not only the irqset allocations, but also if the
device is really supports WRR or not.
> + /* set read,poll,default to medium by default */
> + switch (type) {
> + case HCTX_TYPE_POLL:
> + polled = true;
Question: Is poll-queue not avilable to be used in case of !WRR?
> + case HCTX_TYPE_DEFAULT:
> + case HCTX_TYPE_READ:
> + case HCTX_TYPE_WRR_MEDIUM:
> + wrr = NVME_SQ_PRIO_MEDIUM;
Also it seems like it could be named like flags because it will show the
SQ priority. What do you think?
> + break;
> + case HCTX_TYPE_WRR_LOW:
> + wrr = NVME_SQ_PRIO_LOW;
> + break;
> + case HCTX_TYPE_WRR_HIGH:
> + wrr = NVME_SQ_PRIO_HIGH;
> + break;
> + default:
> + return -EINVAL;
> + }
> + } else {
> + wrr = 0;
Would it be different with the following value ?
NVME_SQ_PRIO_URGENT = (0 << 1)
If it means no WRR, then can it be avoided the value which is already
defined ?
> + }
>
> clear_bit(NVMEQ_DELETE_ERROR, &nvmeq->flags);
>
> @@ -2028,35 +2079,73 @@ static int nvme_setup_host_mem(struct nvme_dev *dev)
> static void nvme_calc_irq_sets(struct irq_affinity *affd, unsigned int nrirqs)
> {
> struct nvme_dev *dev = affd->priv;
> - unsigned int nr_read_queues;
> + unsigned int nr_total, nr, nr_read, nr_default;
> + unsigned int nr_wrr_high, nr_wrr_medium, nr_wrr_low;
> + unsigned int nr_sets;
>
> /*
> * If there is no interupt available for queues, ensure that
> * the default queue is set to 1. The affinity set size is
> * also set to one, but the irq core ignores it for this case.
> - *
> - * If only one interrupt is available or 'write_queue' == 0, combine
> - * write and read queues.
> - *
> - * If 'write_queues' > 0, ensure it leaves room for at least one read
> - * queue.
> */
> - if (!nrirqs) {
> + if (!nrirqs)
> nrirqs = 1;
> - nr_read_queues = 0;
> - } else if (nrirqs == 1 || !write_queues) {
> - nr_read_queues = 0;
> - } else if (write_queues >= nrirqs) {
> - nr_read_queues = 1;
> - } else {
> - nr_read_queues = nrirqs - write_queues;
> - }
>
> - dev->io_queues[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> - affd->set_size[HCTX_TYPE_DEFAULT] = nrirqs - nr_read_queues;
> - dev->io_queues[HCTX_TYPE_READ] = nr_read_queues;
> - affd->set_size[HCTX_TYPE_READ] = nr_read_queues;
> - affd->nr_sets = nr_read_queues ? 2 : 1;
> + nr_total = nrirqs;
> +
> + nr_read = nr_wrr_high = nr_wrr_medium = nr_wrr_low = 0;
> +
> + /* set default to 1, add all the rest queue to default at last */
> + nr = nr_default = 1;
> + nr_sets = 1;
> +
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* read queues */
> + nr_sets++;
> + nr_read = nr = read_queues > nr_total ? nr_total : read_queues;
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr low queues */
> + nr_sets++;
> + nr_wrr_low = nr = wrr_low_queues > nr_total ? nr_total : wrr_low_queues;
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr medium queues */
> + nr_sets++;
> + nr_wrr_medium = nr = wrr_medium_queues > nr_total ? nr_total : wrr_medium_queues;
It looks like exceeded 80 chracters here.
> + nr_total -= nr;
> + if (!nr_total)
> + goto done;
> +
> + /* wrr high queues */
> + nr_sets++;
> + nr_wrr_high = nr = wrr_high_queues > nr_total ? nr_total : wrr_high_queues;
> + nr_wrr_high = nr = wrr_high_queues > nr_total ? nr_total : wrr_high_queues;
Here also.
If I misunderstood something here, please feel free to let me know.
Thanks,
^ permalink raw reply
* Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
From: Paul Cercueil @ 2019-06-20 14:15 UTC (permalink / raw)
To: Sam Ravnborg
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maarten Lankhorst, Maxime Ripard, Sean Paul, od, dri-devel,
devicetree, linux-kernel, Artur Rojek
In-Reply-To: <20190619122622.GB29084@ravnborg.org>
Le mer. 19 juin 2019 à 14:26, Sam Ravnborg <sam@ravnborg.org> a écrit
:
> Hi Paul.
>
> On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote:
>> Add a KMS driver for the Ingenic JZ47xx family of SoCs.
>> This driver is meant to replace the aging jz4740-fb driver.
>>
>> This driver does not make use of the simple pipe helper, for the
>> reason
>> that it will soon be updated to support more advanced features like
>> multiple planes, IPU integration for colorspace conversion and
>> up/down
>> scaling, support for DSI displays, and TV-out and HDMI outputs.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> Tested-by: Artur Rojek <contact@artur-rojek.eu>
>> ---
>>
>> Notes:
>> v2: - Remove custom handling of panel. The panel is now
>> discovered using
>> the standard API.
>> - Lots of small tweaks suggested by upstream
>>
>> v3: - Use devm_drm_dev_init()
>> - Update compatible strings to -lcd instead of -drm
>> - Add destroy() callbacks to plane and crtc
>> - The ingenic,lcd-mode is now read from the bridge's DT node
>>
>> v4: Remove ingenic,lcd-mode property completely. The various
>> modes are now
>> deduced from the connector type, the pixel format or the bus
>> flags.
>>
>> v5: - Fix framebuffer size incorrectly calculated for 24bpp
>> framebuffers
>> - Use 32bpp framebuffer instead of 16bpp, as it'll work with
>> both
>> 16-bit and 24-bit panel
>> - Get rid of drm_format_plane_cpp() which has been dropped
>> upstream
>> - Avoid using drm_format_info->depth, which is deprecated.
> In the drm world we include the revision notes in the changelog.
> So I did this when I applied it to drm-misc-next.
>
> Fixed a few trivial checkpatch warnings about indent too.
> There was a few too-long-lines warnings that I ignored. Fixing them
> would have hurt readability.
Thanks.
> I assume you will maintain this driver onwards from now.
> Please request drm-misc commit rights (see
> https://www.freedesktop.org/wiki/AccountRequests/)
> You will need a legacy SSH account.
I requested an account here:
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/162
> And you should familiarize yourself with the maintainer-tools:
> https://drm.pages.freedesktop.org/maintainer-tools/index.html
>
> For my use I use "dim update-branches; dim apply; dim push
> So only a small subset i needed for simple use.
>
> Sam
^ permalink raw reply
* Re: [PATCH 1/3] HID: wacom: Don't set tool type until we're in range
From: Greg KH @ 2019-06-20 14:15 UTC (permalink / raw)
To: Gerecke, Jason
Cc: stable, Aaron Armstrong Skomra, Benjamin Tissoires, Jason Gerecke,
Aaron Armstrong Skomra
In-Reply-To: <20190617215946.13423-1-jason.gerecke@wacom.com>
On Mon, Jun 17, 2019 at 02:59:46PM -0700, Gerecke, Jason wrote:
> From: Jason Gerecke <jason.gerecke@wacom.com>
>
> The serial number and tool type information that is reported by the tablet
> while a pen is merely "in prox" instead of fully "in range" can be stale
> and cause us to report incorrect tool information. Serial number, tool
> type, and other information is only valid once the pen comes fully in range
> so we should be careful to not use this information until that point.
>
> In particular, this issue may cause the driver to incorectly report
> BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.
>
> Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
> Cc: <stable@vger.kernel.org> # 4.11+
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> Original commit in Linus' tree: 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725
All 3 patches now applied, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] x86/cpufeatures: Enumerate new AVX512 BFLOAT16 instructions
From: Fenghua Yu @ 2019-06-20 14:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: Thomas Gleixner, Ingo Molnar, H Peter Anvin,
Christopherson Sean J, Paolo Bonzini, Radim Krcmar,
Ravi V Shankar, linux-kernel, x86
In-Reply-To: <20190620103720.GB28032@zn.tnic>
On Thu, Jun 20, 2019 at 12:37:20PM +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2019 at 02:34:04PM -0700, Fenghua Yu wrote:
> You need to test the sub-leaf index validity here before accessing
> subleaf 1:
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 4910cb421b82..dad20bc891d5 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -848,8 +848,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> c->x86_capability[CPUID_7_ECX] = ecx;
> c->x86_capability[CPUID_7_EDX] = edx;
>
> - cpuid_count(0x00000007, 1, &eax, &ebx, &ecx, &edx);
> - c->x86_capability[CPUID_7_1_EAX] = eax;
> + /* Check valid sub-leaf index before accessing it */
> + if (eax >= 1) {
> + cpuid_count(0x00000007, 1, &eax, &ebx, &ecx, &edx);
> + c->x86_capability[CPUID_7_1_EAX] = eax;
> + }
You are right.
I tested the three patches in tip tree and they work as expected.
Thank you very much!
-Fenghua
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support
From: Pranith Kumar @ 2019-06-20 13:53 UTC (permalink / raw)
To: Alex Bennée; +Cc: Emilio G. Cota, qemu-devel, rth
In-Reply-To: <20190614171200.21078-1-alex.bennee@linaro.org>
Hi Alex/Emilio,
I am really happy to see the progress you made on the plugin feature. Looking
forward to seeing it merged soon! Please CC me on future versions of the
patchset. I am happy to help review and contribute to this effort.
I have a few general comments from experience writing a very similar system
(qsim) below.
On Fri, Jun 14, 2019 at 10:23 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Hi,
>
> This is v3 of the proposed plugins API for QEMU. As Emilio is busy
> having finished his time at Columbia I have volunteered to take the
> patch series forward. Emilio's RFC v2 was posted last year:
>
> Subject: [RFC v2 00/38] Plugin support
> Date: Sun, 9 Dec 2018 14:37:11 -0500
> Message-Id: <20181209193749.12277-1-cota@braap.org>
>
* Register and memory read/write API
It would be great to have register and memory read/write API i.e., ability
to read/write to registers/memory from within the callback. This gives the
plugin ability to do system introspection. (Not sure if the current patchset
implements this already).
* Register callbacks
A callback needs to be invoked whenever a specified registers is read or
written to.
* Where do new plugins live in the tree?
The current source files in plugins (api, core etc.,) I think are better if
moved to tcg/plugins/. The various plugins we write would then live in the
plugins/ folder instead of the current tests/plugin/ folder.
* Timer interrupts
What I observed is that the system execution is affected by what you do in
the callbacks because of timer interrupts. For example, if you spend time in
the memory callback doing a bit of processing and writing to a file, you
will see more timer interrupt instructions. One solution to this would be to
use 'icount', but it does not work that well. I think we need to do
something similar to what gdb does in debug mode. How would you handle MTTCG
guests in that case?
Another approach would be to offload callback generation to a separate
plugin thread. The main thread will copy data required by a callback and
invoke the callback asynchronously (std::async in C++ if you are familiar).
* Starting and stopping callback generation
It would be great if we have a mechanism to dynamically start/stop callbacks
when a sequence of code (magic instruction) is executed. This would be
useful to annotate region-of-interest (ROI) in benchmarks to
generate callbacks.
Also, the return value from a callback can be used to decide further course
of action. For example, if our plugin needs 10000 callbacks, it can indicate
to stop generating further callbacks in the return value of the callback
once it got the necessary callbacks.
* State saving API
An API to save the state of the VM from the plugin code.
Let me know your thoughts and any other ideas you might have.
Thanks,
--
Pranith
^ permalink raw reply
* Re: [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state
From: Bjorn Helgaas @ 2019-06-20 14:15 UTC (permalink / raw)
To: Mika Westerberg
Cc: Rafael J. Wysocki, Len Brown, Lukas Wunner, Keith Busch,
Alex Williamson, Alexandru Gagniuc, linux-acpi, linux-pci
In-Reply-To: <20190620133710.GB2640@lahna.fi.intel.com>
On Thu, Jun 20, 2019 at 04:37:10PM +0300, Mika Westerberg wrote:
> On Thu, Jun 20, 2019 at 08:16:49AM -0500, Bjorn Helgaas wrote:
> > On Thu, Jun 20, 2019 at 11:27:30AM +0300, Mika Westerberg wrote:
> > > On Wed, Jun 19, 2019 at 04:28:01PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jun 18, 2019 at 07:18:56PM +0300, Mika Westerberg wrote:
> > > > > Intel Ice Lake has an integrated Thunderbolt controller which
> > > > > means that the PCIe topology is extended directly from the two
> > > > > root ports (RP0 and RP1).
> > > >
> > > > A PCIe topology is always extended directly from root ports,
> > > > regardless of whether a Thunderbolt controller is integrated, so I
> > > > guess I'm missing the point you're making. It doesn't sound like
> > > > this is anything specific to Thunderbolt?
> > >
> > > The point I'm trying to make here is to explain why this is problem
> > > now and not with the previous discrete controllers. With the
> > > previous there was only a single ACPI power resource for the root
> > > port and the Thunderbolt host router was connected to that root
> > > port. PCIe hierarchy was extended through downstream ports (not root
> > > ports) of that controller (which includes PCIe switch).
> >
> > Sounds like you're using "PCIe topology extension" to mean
> > specifically something below a Thunderbolt controller, excluding a
> > subtree below a root port. I don't think the PCI core is aware of
> > that distinction.
>
> Right it is not.
>
> > > Now the thing is part of the SoC so power management is different
> > > and causes problems in Linux.
> >
> > The SoC is a physical packaging issue that really doesn't enter into
> > the specs directly. I'm trying to get at the logical topology
> > questions in terms of the PCIe and ACPI specs.
> >
> > I assume we could dream up a non-Thunderbolt topology that would show
> > the same problem?
>
> Yes.
>
> > > > > Power management is handled by ACPI power resources that are
> > > > > shared between the root ports, Thunderbolt controller (NHI) and xHCI
> > > > > controller.
> > > > >
> > > > > The topology with the power resources (marked with []) looks like:
> > > > >
> > > > > Host bridge
> > > > > |
> > > > > +- RP0 ---\
> > > > > +- RP1 ---|--+--> [TBT]
> > > > > +- NHI --/ |
> > > > > | |
> > > > > | v
> > > > > +- xHCI --> [D3C]
> > > > >
> > > > > Here TBT and D3C are the shared ACPI power resources. ACPI
> > > > > _PR3() method returns either TBT or D3C or both.
> >
> > I'm not very familiar with _PR3. I guess this is under an ACPI object
> > representing a PCI device, e.g., \_SB.PCI0.RP0._PR3?
>
> Correct.
>
> > > > > Say we runtime suspend first the root ports RP0 and RP1, then
> > > > > NHI. Now since the TBT power resource is still on when the root
> > > > > ports are runtime suspended their dev->current_state is set to
> > > > > D3hot. When NHI is runtime suspended TBT is finally turned off
> > > > > but state of the root ports remain to be D3hot.
> >
> > So in this example we might have:
> >
> > _SB.PCI0.RP0._PR3: TBT
> > _SB.PCI0.RP1._PR3: TBT
> > _SB.PCI0.NHI._PR3: TBT
>
> and also D3C.
>
> > And when Linux figures out that everything depending on TBT is in
> > D3hot, it evaluates TBT._OFF, which puts them all in D3cold? And part
> > of the problem is that they're now in D3cold (where config access
> > doesn't work) but Linux still thinks they're in D3hot (where config
> > access would work)?
>
> Exactly.
>
> > I feel like I'm missing something because I don't know how D3C is
> > involved, since you didn't mention suspending xHCI.
>
> That's another power resource so we will also have D3C turned off when
> xHCI gets suspended but I did not want to complicate things too much in
> the changelog.
If D3C isn't essential to seeing this problem, you could just omit it
altogether. I think stripping out anything that's not essential will
make it easier to think about the underlying issues.
> > And I can't mentally match up the patch with the D3hot/D3cold state
> > change (if indeed that's the problem). If we were updating the path
> > that evaluates _OFF so it changed the power state of all dependent
> > devices, *that* would make a lot of sense to me because it sounds like
> > that's where the physical change happens that makes things out of
> > sync.
>
> I did that in the first version [1] but Rafael pointed out that it is
> racy one way or another [2].
>
> [1] https://www.spinics.net/lists/linux-pci/msg83583.html
> [2] https://www.spinics.net/lists/linux-pci/msg83600.html
Yeah, interesting. It was definitely a much larger patch. I don't
know enough to comment on the races. I would wonder whether there's a
way to get rid of the caches that become stale, but that's just an
idle thought, not a suggestion.
Bjorn
^ permalink raw reply
* Re: [PATCH v1] backlight: pwm_bl: convert to use SPDX identifier
From: Daniel Thompson @ 2019-06-20 14:14 UTC (permalink / raw)
To: Andy Shevchenko, Thierry Reding, linux-pwm, Lee Jones, Jingoo Han,
dri-devel
In-Reply-To: <20190619135927.29745-1-andriy.shevchenko@linux.intel.com>
On 19/06/2019 14:59, Andy Shevchenko wrote:
> Reduce size of duplicated comments by switching to use SPDX identifier.
>
> No functional change.
>
> While here, correct MODULE_LICENSE() string to be aligned with license text.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> ---
> drivers/video/backlight/pwm_bl.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index fb45f866b923..1f7f8d5c0bf1 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -1,13 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> - * linux/drivers/video/backlight/pwm_bl.c
> - *
> - * simple PWM based backlight control, board code has to setup
> + * Simple PWM based backlight control, board code has to setup
> * 1) pin configuration so PWM waveforms can output
> * 2) platform_data being correctly configured
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> */
>
> #include <linux/delay.h>
> @@ -708,5 +703,5 @@ static struct platform_driver pwm_backlight_driver = {
> module_platform_driver(pwm_backlight_driver);
>
> MODULE_DESCRIPTION("PWM based Backlight Driver");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("platform:pwm-backlight");
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [LTP] [COMMITTED] [PATCH] syscalls/futex: Get rid of futex_common.h
From: Cyril Hrubis @ 2019-06-20 14:14 UTC (permalink / raw)
To: ltp
There is no point in passing fd to anynomous mapping, the fd was ignored
to begin with.
This commit just moves the mmap() to particular tests as there is no
point in having helper just for one mmap() call and removes the
futex_common.h completely.
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
---
.../kernel/syscalls/futex/futex_common.h | 46 -------------------
.../kernel/syscalls/futex/futex_wait02.c | 11 ++++-
.../kernel/syscalls/futex/futex_wake03.c | 11 ++++-
3 files changed, 20 insertions(+), 48 deletions(-)
delete mode 100644 testcases/kernel/syscalls/futex/futex_common.h
diff --git a/testcases/kernel/syscalls/futex/futex_common.h b/testcases/kernel/syscalls/futex/futex_common.h
deleted file mode 100644
index 231fdc67e..000000000
--- a/testcases/kernel/syscalls/futex/futex_common.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Copyright (C) 2015 Cyril Hrubis <chrubis@suse.cz>
- *
- * Licensed under the GNU GPLv2 or later.
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
- * the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
- /*
- * Setups futex in shared memory needed for synchronization between multiple
- * processes.
- */
-
-static futex_t *futex;
-
-static void setup(void)
-{
- int fd;
-
- fd = shm_open("/LTP_futex_wait", O_RDWR | O_CREAT | O_EXCL, 0);
-
- if (fd < 0) {
- tst_brkm(TBROK | TERRNO, NULL,
- "shm_open(/LTP_futex_wait,O_RDWR|O_CREAT|O_EXCL,775)");
- }
- if (shm_unlink("/LTP_futex_wait"))
- tst_brkm(TBROK | TERRNO, NULL, "shm_unlink(/LTP_futex_wait)");
-
- futex = SAFE_MMAP(NULL, NULL, sizeof(*futex), PROT_READ | PROT_WRITE,
- MAP_ANONYMOUS | MAP_SHARED, fd, 0);
-
- SAFE_CLOSE(NULL, fd);
-
- *futex = FUTEX_INITIALIZER;
-}
diff --git a/testcases/kernel/syscalls/futex/futex_wait02.c b/testcases/kernel/syscalls/futex/futex_wait02.c
index 2b863fe7c..1ca1df457 100644
--- a/testcases/kernel/syscalls/futex/futex_wait02.c
+++ b/testcases/kernel/syscalls/futex/futex_wait02.c
@@ -29,11 +29,12 @@
#include "test.h"
#include "safe_macros.h"
#include "futextest.h"
-#include "futex_common.h"
const char *TCID="futex_wait02";
const int TST_TOTAL=1;
+static futex_t *futex;
+
static void do_child(void)
{
int ret;
@@ -81,6 +82,14 @@ static void verify_futex_wait(void)
tst_resm(TFAIL, "child failed");
}
+static void setup(void)
+{
+ futex = SAFE_MMAP(NULL, NULL, sizeof(*futex), PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+
+ *futex = FUTEX_INITIALIZER;
+}
+
int main(int argc, char *argv[])
{
int lc;
diff --git a/testcases/kernel/syscalls/futex/futex_wake03.c b/testcases/kernel/syscalls/futex/futex_wake03.c
index 523f32851..d6e5e5422 100644
--- a/testcases/kernel/syscalls/futex/futex_wake03.c
+++ b/testcases/kernel/syscalls/futex/futex_wake03.c
@@ -27,11 +27,12 @@
#include "test.h"
#include "safe_macros.h"
#include "futextest.h"
-#include "futex_common.h"
const char *TCID="futex_wake03";
const int TST_TOTAL=11;
+static futex_t *futex;
+
static void do_child(void)
{
futex_wait(futex, *futex, NULL, 0);
@@ -103,6 +104,14 @@ static void verify_futex_wake(void)
}
}
+static void setup(void)
+{
+ futex = SAFE_MMAP(NULL, NULL, sizeof(*futex), PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+
+ *futex = FUTEX_INITIALIZER;
+}
+
int main(int argc, char *argv[])
{
int lc;
--
2.19.2
^ permalink raw reply related
* Re: [Qemu-devel] [QEMU PATCH v4 0/10]: target/i386: kvm: Add support for save and restore of nested state
From: Liran Alon @ 2019-06-20 13:28 UTC (permalink / raw)
To: Paolo Bonzini
Cc: ehabkost, kvm, maran.wilson, mtosatti, dgilbert, qemu-devel,
jmattson, rth
In-Reply-To: <bcb617b1-7d20-d2ff-81c5-9f165eae5683@redhat.com>
> On 20 Jun 2019, at 15:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 19/06/19 18:21, Liran Alon wrote:
>> Hi,
>>
>> This series aims to add support for QEMU to be able to migrate VMs that
>> are running nested hypervisors. In order to do so, it utilizes the new
>> IOCTLs introduced in KVM commit 8fcc4b5923af ("kvm: nVMX: Introduce
>> KVM_CAP_NESTED_STATE") which was created for this purpose.
>
> Applied with just three minor changes that should be uncontroversial:
ACK. Where can I see the applied patches for review?
>
>> 6rd patch updates linux-headers to have updated struct kvm_nested_state.
>> The updated struct now have explicit fields for the data portion.
>
> Changed patch title to "linux-headers: sync with latest KVM headers from
> Linux 5.2”
ACK.
>
>> 7rd patch add vmstate support for saving/restoring kernel integer types (e.g. __u16).
>>
>> 8th patch adds support for saving and restoring nested state in order to migrate
>> guests which run a nested hypervisor.
>
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index e924663f32..f3cf6e1b27 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -1671,10 +1671,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
> struct kvm_vmx_nested_state_hdr *vmx_hdr =
> &env->nested_state->hdr.vmx;
>
> + env->nested_state->format = KVM_STATE_NESTED_FORMAT_VMX;
> vmx_hdr->vmxon_pa = -1ull;
> vmx_hdr->vmcs12_pa = -1ull;
> }
> -
> }
>
> cpu->kvm_msr_buf = g_malloc0(MSR_BUF_SIZE);
>
> which is a no-op since KVM_STATE_NESTED_FORMAT_VMX is zero, but it's tidy.
I agree. My bad. Thanks for adding this :)
>
>> 9th patch add support for KVM_CAP_EXCEPTION_PAYLOAD. This new KVM capability
>> allows userspace to properly distingiush between pending and injecting exceptions.
>>
>> 10th patch changes the nested virtualization migration blocker to only
>> be added when kernel lack support for one of the capabilities required
>> for correct nested migration. i.e. Either KVM_CAP_NESTED_STATE or
>> KVM_CAP_EXCEPTION_PAYLOAD.
>
> Had to disable this for SVM unfortunately.
For backwards compatibility I assume… Sounds reasonable to me so ACK.
Even though I must say I would really like to hear your opinion about the thread I had with David Gilbert regarding QEMU’s migration backwards compatibility:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg622274.html
Thanks for the assistance pushing this forward,
-Liran
^ permalink raw reply
* Re: [PATCH 2/3] drm/i915/execlists: Minimalistic timeslicing
From: Mika Kuoppala @ 2019-06-20 14:13 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
In-Reply-To: <156103905257.664.16152371364660528902@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2019-06-20 14:51:24)
>> > +static void
>> > +defer_request(struct i915_request * const rq, struct list_head * const pl)
>> > +{
>> > + struct i915_dependency *p;
>> > +
>> > + /*
>> > + * We want to move the interrupted request to the back of
>> > + * the round-robin list (i.e. its priority level), but
>> > + * in doing so, we must then move all requests that were in
>> > + * flight and were waiting for the interrupted request to
>> > + * be run after it again.
>> > + */
>> > + list_move_tail(&rq->sched.link, pl);
>> > +
>> > + list_for_each_entry(p, &rq->sched.waiters_list, wait_link) {
>> > + struct i915_request *w =
>> > + container_of(p->waiter, typeof(*w), sched);
>> > +
>> > + /* Leave semaphores spinning on the other engines */
>> > + if (w->engine != rq->engine)
>> > + continue;
>> > +
>> > + /* No waiter should start before the active request completed */
>> > + GEM_BUG_ON(i915_request_started(w));
>> > +
>> > + GEM_BUG_ON(rq_prio(w) > rq_prio(rq));
>> > + if (rq_prio(w) < rq_prio(rq))
>> > + continue;
>> > +
>> > + if (list_empty(&w->sched.link))
>> > + continue; /* Not yet submitted; unready */
>> > +
>> > + /*
>> > + * This should be very shallow as it is limited by the
>> > + * number of requests that can fit in a ring (<64) and
>>
>> s/and/or ?
>
> I think "and" works better as each context has their own ring, so it's a
> multiplicative effect.
>
I jumped. But got clarity on irc that this are the contexts in flight.
>> > + * the number of contexts that can be in flight on this
>> > + * engine.
>> > + */
>> > + defer_request(w, pl);
>>
>> So the stack frame will be 64*(3*8 + preample/return) at worst case?
>> can be over 2k
>
> Ok, that makes it sound scary -- but we are well within the 8k irq
> limit. (Even interrupts now have 2 pages iirc, but even at 4k we are
> well within bounds.)
>
Should be safe.
>> > @@ -906,6 +982,27 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
>> > */
>> > last->hw_context->lrc_desc |= CTX_DESC_FORCE_RESTORE;
>> > last = NULL;
>> > + } else if (need_timeslice(engine, last) &&
>> > + !timer_pending(&engine->execlists.timer)) {
>> > + GEM_TRACE("%s: expired last=%llx:%lld, prio=%d, hint=%d\n",
>> > + engine->name,
>> > + last->fence.context,
>> > + last->fence.seqno,
>> > + last->sched.attr.priority,
>> > + execlists->queue_priority_hint);
>> > +
>> > + ring_pause(engine) = 1;
>> > + defer_active(engine);
>> > +
>> > + /*
>> > + * Unlike for preemption, if we rewind and continue
>> > + * executing the same context as previously active,
>> > + * the order of execution will remain the same and
>> > + * the tail will only advance. We do not need to
>> > + * force a full context restore, as a lite-restore
>> > + * is sufficient to resample the monotonic TAIL.
>> > + */
>>
>> I would have asked about the force preemption without this fine comment.
>>
>> But this is a similar as the other kind of preemption. So what happens
>> when the contexts are not the same?
>
> It's just a normal preemption event. The old ring regs are saved and we
> don't try and scribble over them. Any future use of the old context will
> have the same RING_TAIL as before or later (new request) so we will
> never try to program a backwards step.
Ok,
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [MPTCP] [PATCH 3/3] mptcp: move MPTCP option bits to internal header
From: Matthieu Baerts @ 2019-06-20 14:13 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
OPTION_MPTCP_MPJ_* are only used in files from net/mptcp.
Fixes: mptcp: Add handling of incoming MP_JOIN requests
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Notes:
Can be squashed in:
mptcp: Add handling of incoming MP_JOIN requests
include/net/mptcp.h | 4 ----
net/mptcp/protocol.h | 3 +++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 6b4b789b21a2..6cd650838ddf 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -24,10 +24,6 @@ struct mptcp_ext {
__unused:2;
};
-#define OPTION_MPTCP_MPJ_SYN BIT(3)
-#define OPTION_MPTCP_MPJ_SYNACK BIT(4)
-#define OPTION_MPTCP_MPJ_ACK BIT(5)
-
struct mptcp_out_options {
#if IS_ENABLED(CONFIG_MPTCP)
u16 suboptions;
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 2b52e31e709f..be5cdec85997 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -14,6 +14,9 @@
#define OPTION_MPTCP_MPC_SYN BIT(0)
#define OPTION_MPTCP_MPC_SYNACK BIT(1)
#define OPTION_MPTCP_MPC_ACK BIT(2)
+#define OPTION_MPTCP_MPJ_SYN BIT(3)
+#define OPTION_MPTCP_MPJ_SYNACK BIT(4)
+#define OPTION_MPTCP_MPJ_ACK BIT(5)
#define OPTION_MPTCP_ADD_ADDR BIT(6)
#define OPTION_MPTCP_ADD_ADDR6 BIT(7)
#define OPTION_MPTCP_RM_ADDR BIT(8)
--
2.20.1
^ permalink raw reply related
* [MPTCP] [PATCH 2/3] mptcp: move MPTCP option bits to internal header
From: Matthieu Baerts @ 2019-06-20 14:13 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
OPTION_MPTCP_ADD/RM_* are only used in files from net/mptcp.
Fixes: abb537b13f1a (mptcp: Add ADD_ADDR handling)
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Notes:
Can be squashed in:
mptcp: Add ADD_ADDR handling
include/net/mptcp.h | 4 ----
net/mptcp/protocol.h | 4 ++++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index fcfcb4150711..518f10248754 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -24,10 +24,6 @@ struct mptcp_ext {
__unused:2;
};
-#define OPTION_MPTCP_ADD_ADDR BIT(6)
-#define OPTION_MPTCP_ADD_ADDR6 BIT(7)
-#define OPTION_MPTCP_RM_ADDR BIT(8)
-
struct mptcp_out_options {
#if IS_ENABLED(CONFIG_MPTCP)
u16 suboptions;
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index b5305ce55480..6e9569a8d556 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -14,6 +14,10 @@
#define OPTION_MPTCP_MPC_SYN BIT(0)
#define OPTION_MPTCP_MPC_SYNACK BIT(1)
#define OPTION_MPTCP_MPC_ACK BIT(2)
+#define OPTION_MPTCP_ADD_ADDR BIT(6)
+#define OPTION_MPTCP_ADD_ADDR6 BIT(7)
+#define OPTION_MPTCP_RM_ADDR BIT(8)
+
/* MPTCP option subtypes */
#define MPTCPOPT_MP_CAPABLE 0
--
2.20.1
^ permalink raw reply related
* [MPTCP] [PATCH 1/3] mptcp: move MPTCP option bits to internal header
From: Matthieu Baerts @ 2019-06-20 14:13 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
OPTION_MPTCP_MPC_* are only used in files from net/mptcp.
Fixes: d377be723a8a (mptcp: Handle MPTCP TCP options)
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Notes:
Can be squashed in:
mptcp: Handle MPTCP TCP options
include/net/mptcp.h | 5 -----
net/mptcp/protocol.h | 5 +++++
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 0d3e02c6c817..eeb2ef902dfd 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -8,11 +8,6 @@
#ifndef __NET_MPTCP_H
#define __NET_MPTCP_H
-/* MPTCP option subtypes */
-#define OPTION_MPTCP_MPC_SYN BIT(0)
-#define OPTION_MPTCP_MPC_SYNACK BIT(1)
-#define OPTION_MPTCP_MPC_ACK BIT(2)
-
struct mptcp_out_options {
u16 suboptions;
u64 sndr_key;
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index ac57e10ec4ca..74dbc5155ea8 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -7,6 +7,11 @@
#ifndef __MPTCP_PROTOCOL_H
#define __MPTCP_PROTOCOL_H
+/* MPTCP option bits */
+#define OPTION_MPTCP_MPC_SYN BIT(0)
+#define OPTION_MPTCP_MPC_SYNACK BIT(1)
+#define OPTION_MPTCP_MPC_ACK BIT(2)
+
/* MPTCP option subtypes */
#define MPTCPOPT_MP_CAPABLE 0
#define MPTCPOPT_MP_JOIN 1
--
2.20.1
^ permalink raw reply related
* [MPTCP] [PATCH 0/3] mptcp: move MPTCP option bits to internal header
From: Matthieu Baerts @ 2019-06-20 14:13 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
All these OPTION_MPTCP_* are only used in files from net/mptcp.
There are 3 commits to ease the squash.
Matthieu Baerts (3):
mptcp: move MPTCP option bits to internal header
mptcp: move MPTCP option bits to internal header
mptcp: move MPTCP option bits to internal header
include/net/mptcp.h | 11 -----------
net/mptcp/protocol.h | 12 ++++++++++++
2 files changed, 12 insertions(+), 11 deletions(-)
--
2.20.1
^ permalink raw reply
* [Qemu-riscv] [PATCH v1 1/1] tcg/riscv: Fix RISC-VH host build failure
From: Alistair Francis @ 2019-06-20 14:04 UTC (permalink / raw)
To: qemu-devel, qemu-riscv
Cc: palmer, alistair.francis, alistair23, richard.henderson
Commit 269bd5d8 "cpu: Move the softmmu tlb to CPUNegativeOffsetState'
broke the RISC-V host build as there are two variables that are used but
not defined.
This patch renames the undefined variables mask_off and table_off to the
existing (but unused) mask_ofs and table_ofs variables.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
tcg/riscv/tcg-target.inc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tcg/riscv/tcg-target.inc.c b/tcg/riscv/tcg-target.inc.c
index 1f0ae64aae..3e76bf5738 100644
--- a/tcg/riscv/tcg-target.inc.c
+++ b/tcg/riscv/tcg-target.inc.c
@@ -980,8 +980,8 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg addrl,
int table_ofs = fast_ofs + offsetof(CPUTLBDescFast, table);
TCGReg mask_base = TCG_AREG0, table_base = TCG_AREG0;
- tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_TMP0, mask_base, mask_off);
- tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_TMP1, table_base, table_off);
+ tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_TMP0, mask_base, mask_ofs);
+ tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_TMP1, table_base, table_ofs);
tcg_out_opc_imm(s, OPC_SRLI, TCG_REG_TMP2, addrl,
TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS);
--
2.22.0
^ permalink raw reply related
* [PATCH 3/3] timekeeping: add missing _ns functions for coarse accessors
From: Jason A. Donenfeld @ 2019-06-20 14:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason A. Donenfeld, Arnd Bergmann, Thomas Gleixner
In-Reply-To: <20190620141159.15965-1-Jason@zx2c4.com>
This further unifies the accessors for the fast and coarse functions, so
that the same types of functions are available for each. There was also
a bit of confusion with the documentation, which prior advertised a
function that has never existed. Finally, the vanilla ktime_get_coarse()
was omitted from the API originally, so this fills this oversight.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
Documentation/core-api/timekeeping.rst | 10 +++++++---
include/linux/timekeeping.h | 27 ++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/Documentation/core-api/timekeeping.rst b/Documentation/core-api/timekeeping.rst
index ad32085174f8..d5e88f0e06a4 100644
--- a/Documentation/core-api/timekeeping.rst
+++ b/Documentation/core-api/timekeeping.rst
@@ -99,16 +99,20 @@ Coarse and fast access
Some additional variants exist for more specialized cases:
-.. c:function:: ktime_t ktime_get_coarse_boottime( void )
+.. c:function:: ktime_t ktime_get_coarse( void )
+ ktime_t ktime_get_coarse_boottime( void )
ktime_t ktime_get_coarse_real( void )
ktime_t ktime_get_coarse_clocktai( void )
- ktime_t ktime_get_coarse_raw( void )
+
+.. c:function:: u64 ktime_get_coarse_ns( void )
+ u64 ktime_get_boot_coarse_ns( void )
+ u64 ktime_get_real_coarse_ns( void )
+ u64 ktime_get_tai_coarse_ns( void )
.. c:function:: void ktime_get_coarse_ts64( struct timespec64 * )
void ktime_get_coarse_boottime_ts64( struct timespec64 * )
void ktime_get_coarse_real_ts64( struct timespec64 * )
void ktime_get_coarse_clocktai_ts64( struct timespec64 * )
- void ktime_get_coarse_raw_ts64( struct timespec64 * )
These are quicker than the non-coarse versions, but less accurate,
corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index c5d360779fab..3df8e63c704b 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -113,6 +113,33 @@ static inline ktime_t ktime_get_coarse_clocktai(void)
return ktime_get_coarse_with_offset(TK_OFFS_TAI);
}
+static inline ktime_t ktime_get_coarse(void)
+{
+ struct timespec64 ts;
+ ktime_get_coarse_ts64(&ts);
+ return timespec64_to_ktime(ts);
+}
+
+static inline u64 ktime_get_coarse_ns(void)
+{
+ return ktime_to_ns(ktime_get_coarse());
+}
+
+static inline u64 ktime_get_real_coarse_ns(void)
+{
+ return ktime_to_ns(ktime_get_coarse_real());
+}
+
+static inline u64 ktime_get_boot_coarse_ns(void)
+{
+ return ktime_to_ns(ktime_get_coarse_boottime());
+}
+
+static inline u64 ktime_get_tai_coarse_ns(void)
+{
+ return ktime_to_ns(ktime_get_coarse_clocktai());
+}
+
/**
* ktime_mono_to_real - Convert monotonic time to clock realtime
*/
--
2.21.0
^ permalink raw reply related
* [PATCH 2/3] timekeeping: use proper ktime_add when adding nsecs in coarse offset
From: Jason A. Donenfeld @ 2019-06-20 14:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason A. Donenfeld, Arnd Bergmann, Thomas Gleixner
In-Reply-To: <20190620141159.15965-1-Jason@zx2c4.com>
While this doesn't actually amount to a real difference, since the macro
evaluates to the same thing, every place else operates on ktime_t using
these functions, so let's not break the pattern.
Fixes: e3ff9c3678b4 ("timekeeping: Repair ktime_get_coarse*() granularity")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/timekeeping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4c97c9c8c217..db0081a14b90 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -817,7 +817,7 @@ ktime_t ktime_get_coarse_with_offset(enum tk_offsets offs)
} while (read_seqcount_retry(&tk_core.seq, seq));
- return base + nsecs;
+ return ktime_add_ns(base, nsecs);
}
EXPORT_SYMBOL_GPL(ktime_get_coarse_with_offset);
--
2.21.0
^ permalink raw reply related
* [PATCH 1/3] timekeeping: add missing non-_ns functions for fast accessors
From: Jason A. Donenfeld @ 2019-06-20 14:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason A. Donenfeld, Arnd Bergmann, Thomas Gleixner
In-Reply-To: <CAHmME9pyf1AmjWOFFdJFXV9-OBv-ChpKZ130733+x=BtjF62mA@mail.gmail.com>
Previously there was no analogue to get proper ktime_t versions of the
fast variety of ktime invocations. This commit makes the interface
uniform with the other accessors.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
Documentation/core-api/timekeeping.rst | 7 +++-
include/linux/timekeeping.h | 28 ++++++++++++--
kernel/time/timekeeping.c | 52 +++++++++++++-------------
3 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/Documentation/core-api/timekeeping.rst b/Documentation/core-api/timekeeping.rst
index 93cbeb9daec0..ad32085174f8 100644
--- a/Documentation/core-api/timekeeping.rst
+++ b/Documentation/core-api/timekeeping.rst
@@ -94,7 +94,7 @@ different format depending on what is required by the user:
down the seconds to the full seconds of the last timer tick
using the respective reference.
-Coarse and fast_ns access
+Coarse and fast access
-------------------------
Some additional variants exist for more specialized cases:
@@ -125,6 +125,11 @@ Some additional variants exist for more specialized cases:
up to several microseconds on older hardware with an external
clocksource.
+.. c:function:: ktime_t ktime_get_mono_fast_ns( void )
+ ktime_t ktime_get_raw_fast_ns( void )
+ ktime_t ktime_get_boottime_fast_ns( void )
+ ktime_t ktime_get_real_fast_ns( void )
+
.. c:function:: u64 ktime_get_mono_fast_ns( void )
u64 ktime_get_raw_fast_ns( void )
u64 ktime_get_boot_fast_ns( void )
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a8ab0f143ac4..c5d360779fab 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -146,10 +146,30 @@ static inline u64 ktime_get_raw_ns(void)
return ktime_to_ns(ktime_get_raw());
}
-extern u64 ktime_get_mono_fast_ns(void);
-extern u64 ktime_get_raw_fast_ns(void);
-extern u64 ktime_get_boot_fast_ns(void);
-extern u64 ktime_get_real_fast_ns(void);
+extern ktime_t ktime_get_mono_fast(void);
+extern ktime_t ktime_get_raw_fast(void);
+extern ktime_t ktime_get_boottime_fast(void);
+extern ktime_t ktime_get_real_fast(void);
+
+static inline u64 ktime_get_mono_fast_ns(void)
+{
+ return ktime_to_ns(ktime_get_mono_fast());
+}
+
+static inline u64 ktime_get_raw_fast_ns(void)
+{
+ return ktime_to_ns(ktime_get_raw_fast());
+}
+
+static inline u64 ktime_get_boot_fast_ns(void)
+{
+ return ktime_to_ns(ktime_get_boottime_fast());
+}
+
+static inline u64 ktime_get_real_fast_ns(void)
+{
+ return ktime_to_ns(ktime_get_real_fast());
+}
/*
* timespec64/time64_t interfaces utilizing the ktime based ones
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44b726bab4bd..4c97c9c8c217 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -443,41 +443,40 @@ static void update_fast_timekeeper(const struct tk_read_base *tkr,
* of the following timestamps. Callers need to be aware of that and
* deal with it.
*/
-static __always_inline u64 __ktime_get_fast_ns(struct tk_fast *tkf)
+static __always_inline ktime_t __ktime_get_fast(struct tk_fast *tkf)
{
struct tk_read_base *tkr;
unsigned int seq;
- u64 now;
+ ktime_t now;
do {
seq = raw_read_seqcount_latch(&tkf->seq);
tkr = tkf->base + (seq & 0x01);
- now = ktime_to_ns(tkr->base);
-
- now += timekeeping_delta_to_ns(tkr,
+ now = ktime_add_ns(tkr->base,
+ timekeeping_delta_to_ns(tkr,
clocksource_delta(
tk_clock_read(tkr),
tkr->cycle_last,
- tkr->mask));
+ tkr->mask)));
} while (read_seqcount_retry(&tkf->seq, seq));
return now;
}
-u64 ktime_get_mono_fast_ns(void)
+ktime_t ktime_get_mono_fast(void)
{
- return __ktime_get_fast_ns(&tk_fast_mono);
+ return __ktime_get_fast(&tk_fast_mono);
}
-EXPORT_SYMBOL_GPL(ktime_get_mono_fast_ns);
+EXPORT_SYMBOL_GPL(ktime_get_mono_fast);
-u64 ktime_get_raw_fast_ns(void)
+ktime_t ktime_get_raw_fast(void)
{
- return __ktime_get_fast_ns(&tk_fast_raw);
+ return __ktime_get_fast(&tk_fast_raw);
}
-EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
+EXPORT_SYMBOL_GPL(ktime_get_raw_fast);
/**
- * ktime_get_boot_fast_ns - NMI safe and fast access to boot clock.
+ * ktime_get_boottime_fast - NMI safe and fast access to boot clock.
*
* To keep it NMI safe since we're accessing from tracing, we're not using a
* separate timekeeper with updates to monotonic clock and boot offset
@@ -497,47 +496,46 @@ EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
* partially updated. Since the tk->offs_boot update is a rare event, this
* should be a rare occurrence which postprocessing should be able to handle.
*/
-u64 notrace ktime_get_boot_fast_ns(void)
+ktime_t notrace ktime_get_boottime_fast(void)
{
struct timekeeper *tk = &tk_core.timekeeper;
- return (ktime_get_mono_fast_ns() + ktime_to_ns(tk->offs_boot));
+ return ktime_add(ktime_get_mono_fast(), tk->offs_boot);
}
-EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
+EXPORT_SYMBOL_GPL(ktime_get_boottime_fast);
/*
- * See comment for __ktime_get_fast_ns() vs. timestamp ordering
+ * See comment for __ktime_get_fast() vs. timestamp ordering
*/
-static __always_inline u64 __ktime_get_real_fast_ns(struct tk_fast *tkf)
+static __always_inline ktime_t __ktime_get_real_fast(struct tk_fast *tkf)
{
struct tk_read_base *tkr;
unsigned int seq;
- u64 now;
+ ktime_t now;
do {
seq = raw_read_seqcount_latch(&tkf->seq);
tkr = tkf->base + (seq & 0x01);
- now = ktime_to_ns(tkr->base_real);
-
- now += timekeeping_delta_to_ns(tkr,
+ now = ktime_add_ns(tkr->base_real,
+ timekeeping_delta_to_ns(tkr,
clocksource_delta(
tk_clock_read(tkr),
tkr->cycle_last,
- tkr->mask));
+ tkr->mask)));
} while (read_seqcount_retry(&tkf->seq, seq));
return now;
}
/**
- * ktime_get_real_fast_ns: - NMI safe and fast access to clock realtime.
+ * ktime_get_real_fast: - NMI safe and fast access to clock realtime.
*/
-u64 ktime_get_real_fast_ns(void)
+ktime_t ktime_get_real_fast(void)
{
- return __ktime_get_real_fast_ns(&tk_fast_mono);
+ return __ktime_get_real_fast(&tk_fast_mono);
}
-EXPORT_SYMBOL_GPL(ktime_get_real_fast_ns);
+EXPORT_SYMBOL_GPL(ktime_get_real_fast);
/**
* halt_fast_timekeeper - Prevent fast timekeeper from accessing clocksource.
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] tests: kvm: Check for a kernel warning
From: Aaron Lewis @ 2019-06-20 14:12 UTC (permalink / raw)
To: Krish Sadhukhan; +Cc: Jim Mattson, Peter Shier, Marc Orr, kvm
In-Reply-To: <4fdb4b8f-2c8e-c148-6f94-cb51d620a49b@oracle.com>
On Tue, Jun 18, 2019 at 12:38 PM Krish Sadhukhan
<krish.sadhukhan@oracle.com> wrote:
>
>
>
> On 06/18/2019 07:13 AM, Aaron Lewis wrote:
> > On Fri, May 31, 2019 at 7:14 AM Aaron Lewis <aaronlewis@google.com> wrote:
> >> When running with /sys/module/kvm_intel/parameters/unrestricted_guest=N,
> >> test that a kernel warning does not occur informing us that
> >> vcpu->mmio_needed=1. This can happen when KVM_RUN is called after a
> >> triple fault.
> >> This test was made to detect a bug that was reported by Syzkaller
> >> (https://groups.google.com/forum/#!topic/syzkaller/lHfau8E3SOE) and
> >> fixed with commit bbeac2830f4de ("KVM: X86: Fix residual mmio emulation
> >> request to userspace").
> >>
> >> Signed-off-by: Aaron Lewis <aaronlewis@google.com>
> >> Reviewed-by: Jim Mattson <jmattson@google.com>
> >> Reviewed-by: Peter Shier <pshier@google.com>
> >> ---
> >> tools/testing/selftests/kvm/.gitignore | 1 +
> >> tools/testing/selftests/kvm/Makefile | 1 +
> >> .../testing/selftests/kvm/include/kvm_util.h | 2 +
> >> .../selftests/kvm/include/x86_64/processor.h | 2 +
> >> tools/testing/selftests/kvm/lib/kvm_util.c | 36 +++++
> >> .../selftests/kvm/lib/x86_64/processor.c | 16 +++
> >> .../selftests/kvm/x86_64/mmio_warning_test.c | 126 ++++++++++++++++++
> >> 7 files changed, 184 insertions(+)
> >> create mode 100644 tools/testing/selftests/kvm/x86_64/mmio_warning_test.c
> >>
> >> diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore
> >> index df1bf9230a74..41266af0d3dc 100644
> >> --- a/tools/testing/selftests/kvm/.gitignore
> >> +++ b/tools/testing/selftests/kvm/.gitignore
> >> @@ -2,6 +2,7 @@
> >> /x86_64/evmcs_test
> >> /x86_64/hyperv_cpuid
> >> /x86_64/kvm_create_max_vcpus
> >> +/x86_64/mmio_warning_test
> >> /x86_64/platform_info_test
> >> /x86_64/set_sregs_test
> >> /x86_64/smm_test
> >> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> >> index 79c524395ebe..670b938f1049 100644
> >> --- a/tools/testing/selftests/kvm/Makefile
> >> +++ b/tools/testing/selftests/kvm/Makefile
> >> @@ -22,6 +22,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test
> >> TEST_GEN_PROGS_x86_64 += x86_64/smm_test
> >> TEST_GEN_PROGS_x86_64 += x86_64/kvm_create_max_vcpus
> >> TEST_GEN_PROGS_x86_64 += x86_64/vmx_set_nested_state_test
> >> +TEST_GEN_PROGS_x86_64 += x86_64/mmio_warning_test
> >> TEST_GEN_PROGS_x86_64 += dirty_log_test
> >> TEST_GEN_PROGS_x86_64 += clear_dirty_log_test
> >>
> >> diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
> >> index 8c6b9619797d..c5c427c86598 100644
> >> --- a/tools/testing/selftests/kvm/include/kvm_util.h
> >> +++ b/tools/testing/selftests/kvm/include/kvm_util.h
> >> @@ -137,6 +137,8 @@ struct kvm_vm *vm_create_default(uint32_t vcpuid, uint64_t extra_mem_size,
> >> void *guest_code);
> >> void vm_vcpu_add_default(struct kvm_vm *vm, uint32_t vcpuid, void *guest_code);
> >>
> >> +bool vm_is_unrestricted_guest(struct kvm_vm *vm);
> >> +
> >> struct kvm_userspace_memory_region *
> >> kvm_userspace_memory_region_find(struct kvm_vm *vm, uint64_t start,
> >> uint64_t end);
> >> diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h
> >> index 6063d5b2f356..af4d26de32d1 100644
> >> --- a/tools/testing/selftests/kvm/include/x86_64/processor.h
> >> +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h
> >> @@ -303,6 +303,8 @@ static inline unsigned long get_xmm(int n)
> >> return 0;
> >> }
> >>
> >> +bool is_intel_cpu(void);
> >> +
> >> struct kvm_x86_state;
> >> struct kvm_x86_state *vcpu_save_state(struct kvm_vm *vm, uint32_t vcpuid);
> >> void vcpu_load_state(struct kvm_vm *vm, uint32_t vcpuid,
> >> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
> >> index e9113857f44e..b93b09ad9a11 100644
> >> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> >> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
> >> @@ -1584,3 +1584,39 @@ void *addr_gva2hva(struct kvm_vm *vm, vm_vaddr_t gva)
> >> {
> >> return addr_gpa2hva(vm, addr_gva2gpa(vm, gva));
> >> }
> >> +
> >> +/*
> >> + * Is Unrestricted Guest
> >> + *
> >> + * Input Args:
> >> + * vm - Virtual Machine
> >> + *
> >> + * Output Args: None
> >> + *
> >> + * Return: True if the unrestricted guest is set to 'Y', otherwise return false.
> >> + *
> >> + * Check if the unrestricted guest flag is enabled.
> >> + */
> >> +bool vm_is_unrestricted_guest(struct kvm_vm *vm)
> >> +{
> >> + char val = 'N';
> >> + size_t count;
> >> + FILE *f;
> >> +
> >> + if (vm == NULL) {
> >> + /* Ensure that the KVM vendor-specific module is loaded. */
> >> + f = fopen(KVM_DEV_PATH, "r");
> >> + TEST_ASSERT(f != NULL, "Error in opening KVM dev file: %d",
> >> + errno);
> >> + fclose(f);
> >> + }
> >> +
> >> + f = fopen("/sys/module/kvm_intel/parameters/unrestricted_guest", "r");
> >> + if (f) {
> >> + count = fread(&val, sizeof(char), 1, f);
> >> + TEST_ASSERT(count == 1, "Unable to read from param file.");
> >> + fclose(f);
> >> + }
> >> +
> >> + return val == 'Y';
> >> +}
> >> diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> >> index dc7fae9fa424..bcc0e70e1856 100644
> >> --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
> >> +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> >> @@ -1139,3 +1139,19 @@ void vcpu_load_state(struct kvm_vm *vm, uint32_t vcpuid, struct kvm_x86_state *s
> >> r);
> >> }
> >> }
> >> +
> >> +bool is_intel_cpu(void)
> >> +{
> >> + int eax, ebx, ecx, edx;
> >> + const uint32_t *chunk;
> >> + const int leaf = 0;
> >> +
> >> + __asm__ __volatile__(
> >> + "cpuid"
> >> + : /* output */ "=a"(eax), "=b"(ebx),
> >> + "=c"(ecx), "=d"(edx)
> >> + : /* input */ "0"(leaf), "2"(0));
> >> +
> >> + chunk = (const uint32_t *)("GenuineIntel");
> >> + return (ebx == chunk[0] && edx == chunk[1] && ecx == chunk[2]);
> >> +}
> >> diff --git a/tools/testing/selftests/kvm/x86_64/mmio_warning_test.c b/tools/testing/selftests/kvm/x86_64/mmio_warning_test.c
> >> new file mode 100644
> >> index 000000000000..00bb97d76000
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/kvm/x86_64/mmio_warning_test.c
> >> @@ -0,0 +1,126 @@
> >> +/*
> >> + * mmio_warning_test
> >> + *
> >> + * Copyright (C) 2019, Google LLC.
> >> + *
> >> + * This work is licensed under the terms of the GNU GPL, version 2.
> >> + *
> >> + * Test that we don't get a kernel warning when we call KVM_RUN after a
> >> + * triple fault occurs. To get the triple fault to occur we call KVM_RUN
> >> + * on a VCPU that hasn't been properly setup.
> >> + *
> >> + */
> >> +
> >> +#define _GNU_SOURCE
> >> +#include <fcntl.h>
> >> +#include <kvm_util.h>
> >> +#include <linux/kvm.h>
> >> +#include <processor.h>
> >> +#include <pthread.h>
> >> +#include <stdio.h>
> >> +#include <stdlib.h>
> >> +#include <string.h>
> >> +#include <sys/ioctl.h>
> >> +#include <sys/mman.h>
> >> +#include <sys/stat.h>
> >> +#include <sys/types.h>
> >> +#include <sys/wait.h>
> >> +#include <test_util.h>
> >> +#include <unistd.h>
> >> +
> >> +#define NTHREAD 4
> >> +#define NPROCESS 5
> >> +
> >> +struct thread_context {
> >> + int kvmcpu;
> >> + struct kvm_run *run;
> >> +};
> >> +
> >> +void *thr(void *arg)
> >> +{
> >> + struct thread_context *tc = (struct thread_context *)arg;
> >> + int res;
> >> + int kvmcpu = tc->kvmcpu;
> >> + struct kvm_run *run = tc->run;
> >> +
> >> + res = ioctl(kvmcpu, KVM_RUN, 0);
> >> + printf("ret1=%d exit_reason=%d suberror=%d\n",
> >> + res, run->exit_reason, run->internal.suberror);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +void test(void)
> >> +{
> >> + int i, kvm, kvmvm, kvmcpu;
> >> + pthread_t th[NTHREAD];
> >> + struct kvm_run *run;
> >> + struct thread_context tc;
> >> +
> >> + kvm = open("/dev/kvm", O_RDWR);
> >> + TEST_ASSERT(kvm != -1, "failed to open /dev/kvm");
> >> + kvmvm = ioctl(kvm, KVM_CREATE_VM, 0);
> >> + TEST_ASSERT(kvmvm != -1, "KVM_CREATE_VM failed");
> >> + kvmcpu = ioctl(kvmvm, KVM_CREATE_VCPU, 0);
> >> + TEST_ASSERT(kvmcpu != -1, "KVM_CREATE_VCPU failed");
> >> + run = (struct kvm_run *)mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
> >> + kvmcpu, 0);
> >> + tc.kvmcpu = kvmcpu;
> >> + tc.run = run;
> >> + srand(getpid());
> >> + for (i = 0; i < NTHREAD; i++) {
> >> + pthread_create(&th[i], NULL, thr, (void *)(uintptr_t)&tc);
> >> + usleep(rand() % 10000);
> >> + }
> >> + for (i = 0; i < NTHREAD; i++)
> >> + pthread_join(th[i], NULL);
> >> +}
> >> +
> >> +int get_warnings_count(void)
> >> +{
> >> + int warnings;
> >> + FILE *f;
> >> +
> >> + f = popen("dmesg | grep \"WARNING:\" | wc -l", "r");
> >> + fscanf(f, "%d", &warnings);
> >> + fclose(f);
> >> +
> >> + return warnings;
> >> +}
> >> +
> >> +int main(void)
> >> +{
> >> + int warnings_before, warnings_after;
> >> +
> >> + if (!is_intel_cpu()) {
> >> + printf("Must be run on an Intel CPU, skipping test\n");
> >> + exit(KSFT_SKIP);
> >> + }
> >> +
> >> + if (vm_is_unrestricted_guest(NULL)) {
> >> + printf("Unrestricted guest must be disabled, skipping test\n");
> >> + exit(KSFT_SKIP);
> >> + }
> >> +
> >> + warnings_before = get_warnings_count();
> >> +
> >> + for (int i = 0; i < NPROCESS; ++i) {
> >> + int status;
> >> + int pid = fork();
> >> +
> >> + if (pid < 0)
> >> + exit(1);
> >> + if (pid == 0) {
> >> + test();
> >> + exit(0);
> >> + }
> >> + while (waitpid(pid, &status, __WALL) != pid)
> >> + ;
> >> + }
> >> +
> >> + warnings_after = get_warnings_count();
>
> Since you are grep'ing for the word "WARNING", is there a possibility
> that the test can detect a false positive based on Warnings generated
> due to some other cause while it ran ?
>
Yes, this is a possibility, however, it is still a warning and should
still be dealt with. We could special case the grep message to be
more specific to the case we are dealing with here, but I'd prefer to
keep it this way to alert on any warning. That way other warnings,
should they occur, are brought to our attention.
> >> + TEST_ASSERT(warnings_before == warnings_after,
> >> + "Warnings found in kernel. Run 'dmesg' to inspect them.");
> >> +
> >> + return 0;
> >> +}
> >> --
> >> 2.22.0.rc1.311.g5d7573a151-goog
> >>
> > ping
>
^ permalink raw reply
* Re: [PATCH v1] backlight: gpio_backlight: Enable ACPI enumeration
From: Daniel Thompson @ 2019-06-20 14:12 UTC (permalink / raw)
To: Andy Shevchenko, Lee Jones, Jingoo Han, dri-devel
In-Reply-To: <20190619152127.11670-1-andriy.shevchenko@linux.intel.com>
On 19/06/2019 16:21, Andy Shevchenko wrote:
> ACPI allows to enumerate specific devices by using compatible strings.
> Enable that enumeration for GPIO based backlight devices.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/video/backlight/gpio_backlight.c | 23 +++++++++--------------
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
> index e470da95d806..05c12df62b27 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -18,6 +18,7 @@
> #include <linux/of_gpio.h>
> #include <linux/platform_data/gpio_backlight.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/slab.h>
>
> struct gpio_backlight {
> @@ -61,11 +62,10 @@ static int gpio_backlight_probe_dt(struct platform_device *pdev,
> struct gpio_backlight *gbl)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *np = dev->of_node;
> enum gpiod_flags flags;
> int ret;
>
> - gbl->def_value = of_property_read_bool(np, "default-on");
> + gbl->def_value = device_property_read_bool(dev, "default-on");
> flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
>
> gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> @@ -89,26 +89,19 @@ static int gpio_backlight_probe(struct platform_device *pdev)
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> - struct device_node *np = pdev->dev.of_node;
> int ret;
>
> - if (!pdata && !np) {
> - dev_err(&pdev->dev,
> - "failed to find platform data or device tree node.\n");
> - return -ENODEV;
> - }
> -
> gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> if (gbl == NULL)
> return -ENOMEM;
>
> gbl->dev = &pdev->dev;
>
> - if (np) {
> + if (pdev->dev.fwnode) {
> ret = gpio_backlight_probe_dt(pdev, gbl);
> if (ret)
> return ret;
> - } else {
> + } else if (pdata) {
> /*
> * Legacy platform data GPIO retrieveal. Do not expand
> * the use of this code path, currently only used by one
> @@ -129,6 +122,10 @@ static int gpio_backlight_probe(struct platform_device *pdev)
> gbl->gpiod = gpio_to_desc(pdata->gpio);
> if (!gbl->gpiod)
> return -EINVAL;
> + } else {
> + dev_err(&pdev->dev,
> + "failed to find platform data or device tree node.\n");
Should the string also be updated?
If what is updated to acknoledge option to use ACPI then:
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> + return -ENODEV;
> }
>
> memset(&props, 0, sizeof(props));
> @@ -149,19 +146,17 @@ static int gpio_backlight_probe(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_OF
> static struct of_device_id gpio_backlight_of_match[] = {
> { .compatible = "gpio-backlight" },
> { /* sentinel */ }
> };
>
> MODULE_DEVICE_TABLE(of, gpio_backlight_of_match);
> -#endif
>
> static struct platform_driver gpio_backlight_driver = {
> .driver = {
> .name = "gpio-backlight",
> - .of_match_table = of_match_ptr(gpio_backlight_of_match),
> + .of_match_table = gpio_backlight_of_match,
> },
> .probe = gpio_backlight_probe,
> };
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 3/7] rslib: decode_rs: Fix length parameter check
From: Ferdinand Blomqvist @ 2019-06-20 14:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Thomas Gleixner
In-Reply-To: <20190620141039.9874-1-ferdinand.blomqvist@gmail.com>
The length of the data load must be at least one. Or in other words,
there must be room for at least 1 data and nroots parity symbols after
shortening the RS code.
Signed-off-by: Ferdinand Blomqvist <ferdinand.blomqvist@gmail.com>
---
lib/reed_solomon/decode_rs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 3313bf944ff1..22006eaa41e6 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -39,7 +39,7 @@
/* Check length parameter for validity */
pad = nn - nroots - len;
- BUG_ON(pad < 0 || pad >= nn);
+ BUG_ON(pad < 0 || pad >= nn - nroots);
/* Does the caller provide the syndrome ? */
if (s != NULL)
--
2.17.2
^ permalink raw reply related
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.