* Re: [PATCH] megaraid-sas: request irqs later
From: Martin K. Petersen @ 2016-11-14 23:48 UTC (permalink / raw)
To: Tomas Henzl; +Cc: linux-scsi, sumit.saxena, kashyap.desai
In-Reply-To: <1478017922-22655-1-git-send-email-thenzl@redhat.com>
>>>>> "Tomas" == Tomas Henzl <thenzl@redhat.com> writes:
Tomas> It is not good when an irq arrives before driver structures are
Tomas> allocated.
Sumit, Kashyap: Please review!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH] netfilter: Update ip_route_me_harder to consider L3 domain
From: Pablo Neira Ayuso @ 2016-11-14 23:48 UTC (permalink / raw)
To: David Ahern; +Cc: kaber, kadlec, netfilter-devel
In-Reply-To: <6698ac14-9706-88b3-ed1f-0ec47c64fb48@cumulusnetworks.com>
Hi David,
On Mon, Nov 14, 2016 at 04:04:26PM -0700, David Ahern wrote:
> On 11/14/16 3:59 PM, Pablo Neira Ayuso wrote:
> > Does ip6_route_me_harder need an update too?
>
> I have not hit a use case yet. Rather than blindly going through and
> adding l3mdev hooks I would like to tie the changes to known uses
> cases.
Hm, your follow up patch updates nf_send_reset6() but not
nf_send_reset(). Sorry but it strikes me as inconsistent that some
spots are updated and some others are not.
^ permalink raw reply
* Re: [tpmdd-devel] [PATCH RFC 2/2] tpm: refactor tpm2_get_tpm_pt to tpm2_getcap_cmd
From: Jarkko Sakkinen @ 2016-11-14 23:48 UTC (permalink / raw)
To: Nayna; +Cc: moderated list:TPM DEVICE DRIVER, open list,
linux-security-module
In-Reply-To: <20161112000242.63hgv5ujmkr7hy6a@intel.com>
On Fri, Nov 11, 2016 at 04:02:43PM -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 11, 2016 at 09:51:45AM +0530, Nayna wrote:
> >
> >
> > On 10/09/2016 03:44 PM, Jarkko Sakkinen wrote:
> > > Refactored tpm2_get_tpm_pt to tpm2_getcap_cmd, which means that it also
> > > takes capability ID as input. This is required to access
> > > TPM_CAP_HANDLES, which contains metadata needed for swapping transient
> > > data.
> > >
> > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > ---
> > > drivers/char/tpm/tpm.h | 6 +++-
> > > drivers/char/tpm/tpm2-cmd.c | 64 ++++++++++++++++++++---------------------
> > > drivers/char/tpm/tpm_tis_core.c | 3 +-
> > > 3 files changed, 38 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > index 0fab6d5..8176f42 100644
> > > --- a/drivers/char/tpm/tpm.h
> > > +++ b/drivers/char/tpm/tpm.h
> > > @@ -85,6 +85,10 @@ enum tpm2_capabilities {
> > > TPM2_CAP_TPM_PROPERTIES = 6,
> > > };
> > >
> > > +enum tpm2_properties {
> > > + TPM2_PT_FAMILY_INDICATOR = 0x100,
> > > +};
> > > +
> > > enum tpm2_startup_types {
> > > TPM2_SU_CLEAR = 0x0000,
> > > TPM2_SU_STATE = 0x0001,
> > > @@ -485,7 +489,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
> > > int tpm2_unseal_trusted(struct tpm_chip *chip,
> > > struct trusted_key_payload *payload,
> > > struct trusted_key_options *options);
> > > -ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
> > > +ssize_t tpm2_getcap_cmd(struct tpm_chip *chip, u32 cap_id, u32 property_id,
> > > u32 *value, const char *desc);
> > >
> > > int tpm2_auto_startup(struct tpm_chip *chip);
> > > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > > index 2900e18..fcf3d86 100644
> > > --- a/drivers/char/tpm/tpm2-cmd.c
> > > +++ b/drivers/char/tpm/tpm2-cmd.c
> > > @@ -111,13 +111,13 @@ struct tpm2_pcr_extend_in {
> > > u8 digest[TPM_DIGEST_SIZE];
> > > } __packed;
> > >
> > > -struct tpm2_get_tpm_pt_in {
> > > +struct tpm2_getcap_in {
> > > __be32 cap_id;
> > > __be32 property_id;
> > > __be32 property_cnt;
> > > } __packed;
> > >
> > > -struct tpm2_get_tpm_pt_out {
> > > +struct tpm2_getcap_out {
> > > u8 more_data;
> > > __be32 subcap_id;
> > > __be32 property_cnt;
> > > @@ -140,8 +140,8 @@ union tpm2_cmd_params {
> > > struct tpm2_pcr_read_in pcrread_in;
> > > struct tpm2_pcr_read_out pcrread_out;
> > > struct tpm2_pcr_extend_in pcrextend_in;
> > > - struct tpm2_get_tpm_pt_in get_tpm_pt_in;
> > > - struct tpm2_get_tpm_pt_out get_tpm_pt_out;
> > > + struct tpm2_getcap_in getcap_in;
> > > + struct tpm2_getcap_out getcap_out;
> > > struct tpm2_get_random_in getrandom_in;
> > > struct tpm2_get_random_out getrandom_out;
> > > };
> > > @@ -435,16 +435,6 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max)
> > > return total ? total : -EIO;
> > > }
> > >
> > > -#define TPM2_GET_TPM_PT_IN_SIZE \
> > > - (sizeof(struct tpm_input_header) + \
> > > - sizeof(struct tpm2_get_tpm_pt_in))
> > > -
> > > -static const struct tpm_input_header tpm2_get_tpm_pt_header = {
> > > - .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
> > > - .length = cpu_to_be32(TPM2_GET_TPM_PT_IN_SIZE),
> > > - .ordinal = cpu_to_be32(TPM2_CC_GET_CAPABILITY)
> > > -};
> > > -
> > > /**
> > > * Append TPMS_AUTH_COMMAND to the buffer. The buffer must be allocated with
> > > * tpm_buf_alloc().
> > > @@ -750,35 +740,43 @@ out:
> > > return rc;
> > > }
> > >
> > > +#define TPM2_GETCAP_IN_SIZE \
> > > + (sizeof(struct tpm_input_header) + sizeof(struct tpm2_getcap_in))
> > > +
> > > +static const struct tpm_input_header tpm2_getcap_header = {
> > > + .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
> > > + .length = cpu_to_be32(TPM2_GETCAP_IN_SIZE),
> > > + .ordinal = cpu_to_be32(TPM2_CC_GET_CAPABILITY)
> > > +};
> > > +
> > > /**
> > > - * tpm2_get_tpm_pt() - get value of a TPM_CAP_TPM_PROPERTIES type property
> > > - * @chip: TPM chip to use.
> > > - * @property_id: property ID.
> > > - * @value: output variable.
> > > + * tpm2_getcap_cmd() - execute a TPM2_GetCapability command
> > > + * @chip: TPM chip to use
> > > + * @cap_id: capability ID
> > > + * @property_id: property ID
> > > + * @value: value of the property
> > > * @desc: passed to tpm_transmit_cmd()
> > > *
> > > - * 0 is returned when the operation is successful. If a negative number is
> > > - * returned it remarks a POSIX error code. If a positive number is returned
> > > - * it remarks a TPM error.
> > > + * Return: same as with tpm_transmit_cmd
> > > */
> > > -ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id, u32 *value,
> > > - const char *desc)
> > > +ssize_t tpm2_getcap_cmd(struct tpm_chip *chip, u32 cap_id, u32 property_id,
> > > + u32 *value, const char *desc)
> >
> > This function currently returns single value "u32 *value" as output data.
> >
> > Some calling function expect list of values from capabilities output.
> > For eg., get_active_banks() use TPM_CAP_PCRS capability to retrieve list of
> > active banks. And this capability returns array of pcr selections(which is a
> > struct representing each active PCR bank)
> >
> > I was thinking, can we define output parameter as struct of cap_id and union
> > of expected cap_data ?
>
> Unless you have major concerns about performance, which I think are not
> relevant here, calling this in a loop is perfectly adequate and a lot of
> simpler than having a generic version (with moreData handling and
> everything).
>
> I would rather see uses of struct cap_t to shrink than to expand. The
> same goes for other horrific unions that exist today in the driver.
If you are fine with this patch (give Reviewed-by) I can apply this
and add to my 4.10 pull request so that we have common baseline to
develop both event log and the resource manager.
This is a very low risk commit to take to 4.10 because it is only used
for interrupt generation in the TIS driver at the moment.
/Jarkko
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Jeff King @ 2016-11-14 23:48 UTC (permalink / raw)
To: David Turner; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <a57cc9c4a0a840baab5b8123fac9388b@exmbdft7.ad.twosigma.com>
On Mon, Nov 14, 2016 at 11:25:30PM +0000, David Turner wrote:
> > But it does seem to work. At least it doesn't seem to break anything
> > in the test suite, and it fixes the new tests you added. I'd worry
> > that there's some obscure case where the response isn't packetized
> > in the same way.
>
> Overall, this looks good to me. The state machine is pretty clean. I
> think I would have used a tiny buffer for the length field, and then I
> would have regretted it. Your way looks nicer than my unwritten patch
> would have looked.
Heh, I started it that way but you end up dealing with the same states
(they're just implicit in your "how big is my temp buffer" field).
> > +#define READ_ONE_HEX(shift) do { \
> > + int val = hexval(buf[0]); \
> > + if (val < 0) { \
> > + warning("error on %d", *buf); \
> > + rpc->pktline_state = RPC_PKTLINE_ERROR; \
> > + return; \
> > + } \
> > + rpc->pktline_len |= val << shift; \
>
> Nit: parenthesize shift here, since it is a parameter to a macro.
Yeah, I'm often a bit slack on these one-off inside-a-function macros.
But it does not hurt to to be careful.
I'll make that change and then try to wrap this up with a commit
message. I plan to steal your tests, if that's OK.
-Peff
^ permalink raw reply
* Re: [PATCH] fnic: remove a pointless test
From: Martin K. Petersen @ 2016-11-14 23:48 UTC (permalink / raw)
To: Tomas Henzl; +Cc: linux-scsi, sramars, hiralpat, buchino
In-Reply-To: <1478018421-22820-1-git-send-email-thenzl@redhat.com>
>>>>> "Tomas" == Tomas Henzl <thenzl@redhat.com> writes:
Tomas> rport can't be null here, it would have failed already in
Tomas> fc_remote_port_chkready
Cisco folks: Please review!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in __sk_mem_raise_allocated()
From: Eric Dumazet @ 2016-11-14 23:49 UTC (permalink / raw)
To: Andrei Vagin; +Cc: Linux Kernel Network Developers, Paolo Abeni
In-Reply-To: <1479166501.8455.91.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-11-14 at 15:35 -0800, Eric Dumazet wrote:
>
> Thanks for the report.
>
> I guess following patch would be needed ?
>
> diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
> index af817158d830c0da080935ba29e012dffbb89112..12604c0371c451efcc9aad278bb86be9ac4bb813 100644
> --- a/net/ipv4/udplite.c
> +++ b/net/ipv4/udplite.c
> @@ -54,6 +54,7 @@ struct proto udplite_prot = {
> .hash = udp_lib_hash,
> .unhash = udp_lib_unhash,
> .get_port = udp_v4_get_port,
> + .memory_allocated = &udp_memory_allocated,
> .obj_size = sizeof(struct udp_sock),
> .h.udp_table = &udplite_table,
> #ifdef CONFIG_COMPAT
> diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
> index 47d0d2b87106558fece3496479198005c55b99e7..946025c888cc9519fb3523edbbe8afbb18273326 100644
> --- a/net/ipv6/udplite.c
> +++ b/net/ipv6/udplite.c
> @@ -49,6 +49,7 @@ struct proto udplitev6_prot = {
> .hash = udp_lib_hash,
> .unhash = udp_lib_unhash,
> .get_port = udp_v6_get_port,
> + .memory_allocated = &udp_memory_allocated,
> .obj_size = sizeof(struct udp6_sock),
> .h.udp_table = &udplite_table,
> #ifdef CONFIG_COMPAT
>
.sysctl_mem also needs to be set.
^ permalink raw reply
* Re: [PATCH 00/11] hisi_sas: some fixes, improvements, and new features
From: Martin K. Petersen @ 2016-11-14 23:49 UTC (permalink / raw)
To: John Garry
Cc: martin.petersen, jejb, linux-scsi, linuxarm, linux-kernel,
john.garry2
In-Reply-To: <1478522920-108145-1-git-send-email-john.garry@huawei.com>
>>>>> "John" == John Garry <john.garry@huawei.com> writes:
John> This patchset introduces some misc bug fixes, improvements, and
John> new features to the HiSilicon SAS driver.
This series needs review.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH] netfilter: Update ip_route_me_harder to consider L3 domain
From: Pablo Neira Ayuso @ 2016-11-14 23:49 UTC (permalink / raw)
To: David Ahern; +Cc: kaber, kadlec, netfilter-devel
In-Reply-To: <20161114234817.GA9609@salvia>
On Tue, Nov 15, 2016 at 12:48:17AM +0100, Pablo Neira Ayuso wrote:
> Hi David,
>
> On Mon, Nov 14, 2016 at 04:04:26PM -0700, David Ahern wrote:
> > On 11/14/16 3:59 PM, Pablo Neira Ayuso wrote:
> > > Does ip6_route_me_harder need an update too?
> >
> > I have not hit a use case yet. Rather than blindly going through and
> > adding l3mdev hooks I would like to tie the changes to known uses
> > cases.
>
> Hm, your follow up patch updates nf_send_reset6() but not
> nf_send_reset(). Sorry but it strikes me as inconsistent that some
> spots are updated and some others are not.
What usecases you have in mind, btw? I can help testing other
scenarios and fix other spots too if it makes sense to do it in one
go.
^ permalink raw reply
* [PATCH] blk-mq drivers: untangle 0 and BLK_MQ_RQ_QUEUE_OK
From: Omar Sandoval @ 2016-11-14 23:49 UTC (permalink / raw)
From: Omar Sandoval <osandov@fb.com>
Let's not depend on any of the BLK_MQ_RQ_QUEUE_* constants having
specific values. No functional change.
Signed-off-by: Omar Sandoval <osandov at fb.com>
---
Hi, Jens,
Some more trivial cleanup, feel free to apply or not if it's too intrusive.
drivers/nvme/host/core.c | 4 ++--
drivers/nvme/host/pci.c | 8 ++++----
drivers/nvme/host/rdma.c | 2 +-
drivers/nvme/target/loop.c | 6 +++---
drivers/scsi/scsi_lib.c | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 79e679d..e7f9ef5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -276,7 +276,7 @@ static inline int nvme_setup_discard(struct nvme_ns *ns, struct request *req,
*/
req->__data_len = nr_bytes;
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static inline void nvme_setup_rw(struct nvme_ns *ns, struct request *req,
@@ -324,7 +324,7 @@ static inline void nvme_setup_rw(struct nvme_ns *ns, struct request *req,
int nvme_setup_cmd(struct nvme_ns *ns, struct request *req,
struct nvme_command *cmd)
{
- int ret = 0;
+ int ret = BLK_MQ_RQ_QUEUE_OK;
if (req->cmd_type == REQ_TYPE_DRV_PRIV)
memcpy(cmd, req->cmd, sizeof(*cmd));
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0248d0e..4afa2f7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -328,7 +328,7 @@ static int nvme_init_iod(struct request *rq, unsigned size,
rq->retries = 0;
rq->cmd_flags |= REQ_DONTPREP;
}
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static void nvme_free_iod(struct nvme_dev *dev, struct request *req)
@@ -598,17 +598,17 @@ static int nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
map_len = nvme_map_len(req);
ret = nvme_init_iod(req, map_len, dev);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
ret = nvme_setup_cmd(ns, req, &cmnd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
if (req->nr_phys_segments)
ret = nvme_map_data(dev, req, map_len, &cmnd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
cmnd.common.command_id = req->tag;
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 5a83881..125c43b 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1399,7 +1399,7 @@ static int nvme_rdma_queue_rq(struct blk_mq_hw_ctx *hctx,
sizeof(struct nvme_command), DMA_TO_DEVICE);
ret = nvme_setup_cmd(ns, rq, c);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
c->common.command_id = rq->tag;
diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
index d5df77d..01035fb 100644
--- a/drivers/nvme/target/loop.c
+++ b/drivers/nvme/target/loop.c
@@ -168,7 +168,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
int ret;
ret = nvme_setup_cmd(ns, req, &iod->cmd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
iod->cmd.common.flags |= NVME_CMD_SGL_METABUF;
@@ -178,7 +178,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
nvme_cleanup_cmd(req);
blk_mq_start_request(req);
nvme_loop_queue_response(&iod->req);
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
if (blk_rq_bytes(req)) {
@@ -197,7 +197,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
blk_mq_start_request(req);
schedule_work(&iod->work);
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static void nvme_loop_submit_async_event(struct nvme_ctrl *arg, int aer_idx)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2cca9cf..13887c0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1801,7 +1801,7 @@ static inline int prep_to_mq(int ret)
{
switch (ret) {
case BLKPREP_OK:
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
case BLKPREP_DEFER:
return BLK_MQ_RQ_QUEUE_BUSY;
default:
@@ -1888,7 +1888,7 @@ static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
int reason;
ret = prep_to_mq(scsi_prep_state_check(sdev, req));
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
ret = BLK_MQ_RQ_QUEUE_BUSY;
@@ -1905,7 +1905,7 @@ static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
if (!(req->cmd_flags & REQ_DONTPREP)) {
ret = prep_to_mq(scsi_mq_prep_fn(req));
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out_dec_host_busy;
req->cmd_flags |= REQ_DONTPREP;
} else {
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 00/11] hisi_sas: some fixes, improvements, and new features
From: Martin K. Petersen @ 2016-11-14 23:49 UTC (permalink / raw)
To: John Garry
Cc: martin.petersen, jejb, linux-scsi, linuxarm, linux-kernel,
john.garry2
In-Reply-To: <1478522920-108145-1-git-send-email-john.garry@huawei.com>
>>>>> "John" == John Garry <john.garry@huawei.com> writes:
John> This patchset introduces some misc bug fixes, improvements, and
John> new features to the HiSilicon SAS driver.
This series needs review.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH] blk-mq drivers: untangle 0 and BLK_MQ_RQ_QUEUE_OK
From: Omar Sandoval @ 2016-11-14 23:49 UTC (permalink / raw)
To: linux-block; +Cc: linux-nvme, linux-scsi, kernel-team
From: Omar Sandoval <osandov@fb.com>
Let's not depend on any of the BLK_MQ_RQ_QUEUE_* constants having
specific values. No functional change.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
Hi, Jens,
Some more trivial cleanup, feel free to apply or not if it's too intrusive.
drivers/nvme/host/core.c | 4 ++--
drivers/nvme/host/pci.c | 8 ++++----
drivers/nvme/host/rdma.c | 2 +-
drivers/nvme/target/loop.c | 6 +++---
drivers/scsi/scsi_lib.c | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 79e679d..e7f9ef5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -276,7 +276,7 @@ static inline int nvme_setup_discard(struct nvme_ns *ns, struct request *req,
*/
req->__data_len = nr_bytes;
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static inline void nvme_setup_rw(struct nvme_ns *ns, struct request *req,
@@ -324,7 +324,7 @@ static inline void nvme_setup_rw(struct nvme_ns *ns, struct request *req,
int nvme_setup_cmd(struct nvme_ns *ns, struct request *req,
struct nvme_command *cmd)
{
- int ret = 0;
+ int ret = BLK_MQ_RQ_QUEUE_OK;
if (req->cmd_type == REQ_TYPE_DRV_PRIV)
memcpy(cmd, req->cmd, sizeof(*cmd));
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0248d0e..4afa2f7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -328,7 +328,7 @@ static int nvme_init_iod(struct request *rq, unsigned size,
rq->retries = 0;
rq->cmd_flags |= REQ_DONTPREP;
}
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static void nvme_free_iod(struct nvme_dev *dev, struct request *req)
@@ -598,17 +598,17 @@ static int nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
map_len = nvme_map_len(req);
ret = nvme_init_iod(req, map_len, dev);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
ret = nvme_setup_cmd(ns, req, &cmnd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
if (req->nr_phys_segments)
ret = nvme_map_data(dev, req, map_len, &cmnd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
cmnd.common.command_id = req->tag;
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 5a83881..125c43b 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1399,7 +1399,7 @@ static int nvme_rdma_queue_rq(struct blk_mq_hw_ctx *hctx,
sizeof(struct nvme_command), DMA_TO_DEVICE);
ret = nvme_setup_cmd(ns, rq, c);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
c->common.command_id = rq->tag;
diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
index d5df77d..01035fb 100644
--- a/drivers/nvme/target/loop.c
+++ b/drivers/nvme/target/loop.c
@@ -168,7 +168,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
int ret;
ret = nvme_setup_cmd(ns, req, &iod->cmd);
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
return ret;
iod->cmd.common.flags |= NVME_CMD_SGL_METABUF;
@@ -178,7 +178,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
nvme_cleanup_cmd(req);
blk_mq_start_request(req);
nvme_loop_queue_response(&iod->req);
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
if (blk_rq_bytes(req)) {
@@ -197,7 +197,7 @@ static int nvme_loop_queue_rq(struct blk_mq_hw_ctx *hctx,
blk_mq_start_request(req);
schedule_work(&iod->work);
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
}
static void nvme_loop_submit_async_event(struct nvme_ctrl *arg, int aer_idx)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2cca9cf..13887c0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1801,7 +1801,7 @@ static inline int prep_to_mq(int ret)
{
switch (ret) {
case BLKPREP_OK:
- return 0;
+ return BLK_MQ_RQ_QUEUE_OK;
case BLKPREP_DEFER:
return BLK_MQ_RQ_QUEUE_BUSY;
default:
@@ -1888,7 +1888,7 @@ static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
int reason;
ret = prep_to_mq(scsi_prep_state_check(sdev, req));
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out;
ret = BLK_MQ_RQ_QUEUE_BUSY;
@@ -1905,7 +1905,7 @@ static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
if (!(req->cmd_flags & REQ_DONTPREP)) {
ret = prep_to_mq(scsi_mq_prep_fn(req));
- if (ret)
+ if (ret != BLK_MQ_RQ_QUEUE_OK)
goto out_dec_host_busy;
req->cmd_flags |= REQ_DONTPREP;
} else {
--
2.10.2
^ permalink raw reply related
* [PATCH] ARM: socfpga: fix spelling mistake in error message
From: Dinh Nguyen @ 2016-11-14 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230400.5352-1-colin.king@canonical.com>
On Mon, Nov 14, 2016 at 5:04 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake "Mananger" to "Manager"
> in error message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/arm/mach-socfpga/l2_cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied!
Thanks,
DInh
^ permalink raw reply
* Re: [PATCH] ARM: socfpga: fix spelling mistake in error message
From: Dinh Nguyen @ 2016-11-14 23:52 UTC (permalink / raw)
To: Colin King
Cc: Dinh Nguyen, Russell King, linux-arm-kernel@lists.infradead.org,
Linux List
In-Reply-To: <20161114230400.5352-1-colin.king@canonical.com>
On Mon, Nov 14, 2016 at 5:04 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake "Mananger" to "Manager"
> in error message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/arm/mach-socfpga/l2_cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied!
Thanks,
DInh
^ permalink raw reply
* Re: [PATCH] netfilter: Update ip_route_me_harder to consider L3 domain
From: David Ahern @ 2016-11-14 23:53 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: kaber, kadlec, netfilter-devel
In-Reply-To: <20161114234942.GA9640@salvia>
On 11/14/16 4:49 PM, Pablo Neira Ayuso wrote:
> On Tue, Nov 15, 2016 at 12:48:17AM +0100, Pablo Neira Ayuso wrote:
>> Hi David,
>>
>> On Mon, Nov 14, 2016 at 04:04:26PM -0700, David Ahern wrote:
>>> On 11/14/16 3:59 PM, Pablo Neira Ayuso wrote:
>>>> Does ip6_route_me_harder need an update too?
>>>
>>> I have not hit a use case yet. Rather than blindly going through and
>>> adding l3mdev hooks I would like to tie the changes to known uses
>>> cases.
>>
>> Hm, your follow up patch updates nf_send_reset6() but not
>> nf_send_reset(). Sorry but it strikes me as inconsistent that some
>> spots are updated and some others are not.
>
> What usecases you have in mind, btw? I can help testing other
> scenarios and fix other spots too if it makes sense to do it in one
> go.
>
As mentioned in the commit message, both this one and the IPV6 one get the REJECT target working for tcp-reset:
iptables -I OUTPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset
ip6tables -A OUTPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset
^ permalink raw reply
* Re: [PATCH RFC] xfs: drop SYNC_WAIT from xfs_reclaim_inodes_ag during slab reclaim
From: Dave Chinner @ 2016-11-14 23:58 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-xfs
In-Reply-To: <1f19925d-6ba8-9bde-b3a8-0bdade80f564@fb.com>
[-- Attachment #1: Type: text/plain, Size: 11106 bytes --]
On Mon, Nov 14, 2016 at 03:56:14PM -0500, Chris Mason wrote:
> On 11/14/2016 02:27 AM, Dave Chinner wrote:
> >On Sun, Nov 13, 2016 at 08:00:04PM -0500, Chris Mason wrote:
> >>On Tue, Oct 18, 2016 at 01:03:24PM +1100, Dave Chinner wrote:
> >>
> >>[ Long stalls from xfs_reclaim_inodes_ag ]
> >>
> >>>XFS has *1* tunable that can change the behaviour of metadata
> >>>writeback. Please try it.
> >>
> >>[ weeks go by, so this email is insanely long ]
> >>
> >>Testing all of this was slow going because two of the three test
> >>boxes I had with the hadoop configuration starting having hardware
> >>problems. The good news is that while I was adjusting the
> >>benchmark, we lined up access to a bunch of duplicate boxes, so I
> >>can now try ~20 different configurations in parallel.
> >>
> >>My rough benchmark is here:
> >>
> >>git://git.kernel.org/pub/scm/linux/kernel/git/mason/simoop.git
> >>
> >>The command line I ended up using was:
> >>
> >>simoop -t 512 -m 190 -M 128 -C 28 -r 60000 -f 70 -T 20 -R1 -W 1 -i
> >>60 -w 300 -D 2 /hammer/*
> >
> >There's a lightly tested patch below that should do the trick.
> >
> >After 5 minutes on a modified simoop cli on a single filesystem,
> >4.9-rc4+for-next:
> >
> >$ ./simoop -t 128 -m 50 -M 128 -C 14 -r 60000 -f 2 -T 20 -R1 -W 1 -i 60 -w 300 -D 2 /mnt/scratch
> >....
> >Run time: 300 seconds
> >Read latency (p50: 3,174,400) (p95: 4,530,176) (p99: 18,055,168)
> >Write latency (p50: 14,991,360) (p95: 28,672,000) (p99: 33,325,056)
> >Allocation latency (p50: 1,771,520) (p95: 17,530,880) (p99: 23,756,800)
> >work rate = 4.75/sec (avg 5.24/sec) (p50: 5.79) (p95: 6.99) (p99: 6.99)
> >alloc stall rate = 94.42/sec (avg: 51.63) (p50: 51.60) (p95: 59.12) (p99: 59.12)
> >
> >With the patch below:
> >
> >Run time: 300 seconds
> >Read latency (p50: 3,043,328) (p95: 3,649,536) (p99: 4,710,400)
> >Write latency (p50: 21,004,288) (p95: 27,557,888) (p99: 29,130,752)
> >Allocation latency (p50: 280,064) (p95: 680,960) (p99: 863,232)
> >work rate = 4.08/sec (avg 4.76/sec) (p50: 5.39) (p95: 6.93) (p99: 6.93)
> >alloc stall rate = 0.08/sec (avg: 0.02) (p50: 0.00) (p95: 0.01) (p99: 0.01)
> >
> >Stall rate went to zero and stayed there at the 120s mark of the
> >warmup. Note the p99 difference for read and allocation latency,
> >too.
> >
> >I'll post some graphs tomorrow from my live PCP telemetry that
> >demonstrate the difference in behaviour better than any words...
>
> Thanks Dave, this is definitely better. But at least for the
> multi-disk setup, it's not quite there yet.
I can see why now I've run the test for half an hour to get a decent
idea of steady state behaviour. I'll come back to that....
> Your patch:
> ___
> Run time: 15535 seconds
> Read latency (p50: 22,708,224) (p95: 34,668,544) (p99: 41,746,432)
> Write latency (p50: 21,200,896) (p95: 34,799,616) (p99: 41,877,504)
> Allocation latency (p50: 11,550,720) (p95: 31,424,512) (p99: 39,518,208)
> work rate = 7.48/sec (avg 8.41/sec) (p50: 8.69) (p95: 9.57) (p99: 9.87)
> alloc stall rate = 14.08/sec (avg: 14.85) (p50: 15.74) (p95: 19.74)
> (p99: 22.04)
>
> Original patch:
> ___
> Run time: 15474 seconds
> Read latency (p50: 20,414,464) (p95: 29,786,112) (p99: 34,275,328)
> Write latency (p50: 15,155,200) (p95: 25,591,808) (p99: 31,621,120)
> Allocation latency (p50: 7,675,904) (p95: 22,970,368) (p99: 29,523,968)
> work rate = 8.33/sec (avg 10.54/sec) (p50: 10.54) (p95: 10.58) (p99: 10.58)
> alloc stall rate = 37.08/sec (avg: 21.73) (p50: 23.16) (p95: 24.68)
> (p99: 25.00)
Ok, so stall rate is down, but the latencies are still garbage
because stalls are happening.
> I've had this running all day, but the differences stabilized after
> 5-10 minutes. Everyone's p99s trend higher as the day goes on, but
> the percentage difference stays about the same.
Right - they stabilise after the first few stalls because they
dominate the p99 numbers. For example, with my patch, I saw the
first stall event between 1080 and 1140 seconds - you can see this
clearly in the 3rd chart:
Run time: 1080 seconds
Read latency (p50: 3,035,136) (p95: 4,284,416) (p99: 5,349,376)
Write latency (p50: 27,623,424) (p95: 31,031,296) (p99: 45,154,304)
Allocation latency (p50: 240,384) (p95: 709,632) (p99: 1,308,672)
work rate = 3.75/sec (avg 3.71/sec) (p50: 3.71) (p95: 4.04) (p99: 4.04)
alloc stall rate = 0.65/sec (avg: 0.04) (p50: 0.00) (p95: 0.03) (p99: 0.03)
du thread is done /mnt/scratch
___
Run time: 1140 seconds
Read latency (p50: 3,035,136) (p95: 4,415,488) (p99: 6,119,424)
Write latency (p50: 27,557,888) (p95: 31,490,048) (p99: 45,285,376)
Allocation latency (p50: 247,552) (p95: 1,497,088) (p99: 19,496,960)
work rate = 3.68/sec (avg 3.71/sec) (p50: 3.71) (p95: 4.04) (p99: 4.04)
alloc stall rate = 1.65/sec (avg: 0.12) (p50: 0.00) (p95: 0.12) (p99: 0.12)
du thread is running /mnt/scratch
So a single "stall event" blows out the p99 latencies really badly.
This is probably the single most important revelation about this
so far...
> I think the difference between mine and yours is we didn't quite get
> the allocation stalls down to zero, so making tasks wait for the
> shrinker shows up in the end numbers.
Right, but so far we haven't answered the obvious question: what
triggers the stall events?
> For your patch, the stalls from xfs_reclaim_inodes_ag() were about
> the same as the unpatched kernel yesterday. We still had long tails
> in the 30 second+ category.
Because when a stall happens, it's doing more than just trashing the
inode cache. The 4 charts I've attached in a tarball are:
Chart 1: unpatched kernel, inode/dentry/xfs_inode cache usage
Chart 2: unpatched kernel, memory usage
Chart 3: unpatched kernel, inode/dentry/xfs_inode cache usage
Chart 4: unpatched kernel, memory usage
These are taken with a 5s sample period, so we're looking at overall
trends, not fine grained behaviour. Things to note:
- discontinuities in the graphs indicate an unresponsive
machine and samples were lost. Good sign that the machine
is stalling on memory allocation
- dentry/vfs inode counts come from
/proc/sys/fs/{dentry,inode}_state
- memory usage chart: "other" is userspace and kernel memory
other than the page cache ("cached").
- cached + other + free = 16GB (all memory)
- "slab" is a subset of "other", but is split out above
16GB so i can easily see salb cache memory usage
- "dirty" is a subset of "cached", but is split out so I can
see how much of the page cache is dirty.
Now, with that in mind, let's compare the graphs. Let's start with
the inode/dentry/xfs_inode cache usage. We can see that the
unpatched kernel has rapid rises and falls in cache footprint. The
vertical falling edges are evidence of allocation stalls. You can
see that it's somewhat regular - the lines stay roughly level, then
we see a deep, sharp valley where the caches are completely freed
and then immediately repopulate.
This generally co-incides with periodic "du scan" starting - it adds
new memory pressure, tipping the kernel into memory reclaim, which
immediately stalls and trashes the cache. Given that there is now
lots of memory free, the du runs at several thousand IOPS (SSDs,
remember) and immediately refills the cache and finishes, producing
no more memory pressure. The cache then sits at the "full" level
until du starts again and we fall off the cliff again.
If we switch to the memory usage graph for the unpatched kernel
(chart 2), we can see that allocation stalls trash more than just
the slab caches - they clean all memory and free all the page cache,
too. i.e. it completely trashes any working set that we might have.
This is not caused by the shrinker - it has no effect on page cache
reclaim. It appears that page reclaim code is, for some reason,
agressively freeing the page cache for multiple seconds, even after
there is already noticable free memory. This is probably an issue
with there being too much direct reclaim stalling due to pressure
(e.g. on dirty pages), and then when the cork is pulled we've got
lots of threads that then run a full direct reclaim scan and that
empties the caches...
/me has always said unbound concurrency in memory reclaim and IO
writeback is a bad thing because you cannot control and limit
behaviour in overload situations like this.
Anyway, lets look at the patched kernel inode cache behaviour -
chart 3. The first thing to note is that there is a very different
pattern - there's a very regular triangular waveform. The trough
occurs when the du thread starts, and the peak occurs when the du
thread stops. IOWs, the inode cache is no longer retaining single
use inodes in the cache for extended periods. The waveform is neat
and regular, and it's very clear where the allocation stall at
~1100s occurred - there's a reclaim cliff.
If we look at chart 4 right now - the patched kernel memory usage -
we can see there is a big dip in the page cache, too. So when an
allocation stall event occurs, the bad behaviour is still there.
However, the way the system responds to a stall event is very
different - it doesn't immediately refill the inode cache. It goes
back to the triangle waveform until the next stall occurs.
What is particularly interesting in chart 3 is the vfs.inodes.count
and xfs_inode slab metrics (red and pink lines respectively). The
active xfs_inode slab objects starts off below the vfs inode count,
then over time 6 cycles xfs_inode count slowly increases above th
vfs inode count. Then we get an allocation stall event, and it
returns the xfs_inode count to less than the vfs inode count. The
second stall even occurs at a similar point.
The xfs_inode > vfs inode count values indicate that we've got XFs
inodes in the reclaim state and that reclaim of XFs inodes is not
keeping up with the VFS inode cache reclaim rate. This is indicative
of either dirty inodes being reclaimed, or we are not putting enough
pressure on the XFS inode cache and so it's putting additional
pressure on other parts of memory reclaim. This change in balance
seems to correlate to allocation stalls being triggered, so I'm
going to try to remove that imbalance and see if that avoids the
allocation stalls.
IOWs, I'm not using latency stats to guide me - they tell me nothing
useful about what causes the latency. The charts tell me when there
is a reclaim issue - I can see it clear as anything. If the graphs
are smooth, maintain a consistent relationship to each other and
behave nicely when there are step changes in behaviour then
everything else will take care of itself.
It's easy to get lost in creating fancy histograms with shiny new
tools like ebpf/bcc, but this is mostly wasted effort when it comes
to finding the cause of the problem. Latency histograms don't help
us understand why the latencies occur, nor do they help track down
the cause. The charts I have show that there is an obvious, one-off,
large scale memory reclaim event that is causing the stalls and bad
latencies. Finding the trigger for that large scale event is what
matters, not pretty histograms of it's effect...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
[-- Attachment #2: charts.tar.gz --]
[-- Type: application/gzip, Size: 81821 bytes --]
^ permalink raw reply
* Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in __sk_mem_raise_allocated()
From: Andrei Vagin @ 2016-11-14 23:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, Paolo Abeni
In-Reply-To: <1479166501.8455.91.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, Nov 14, 2016 at 3:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2016-11-14 at 15:24 -0800, Andrei Vagin wrote:
>> Hi Paolo,
>>
>> Our test system detected a kernel oops. Looks like a problem in the
>> "udp: refactor memory accounting" series.
>>
>> # good: [f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb] udp: implement
>> memory accounting helpers
>> git bisect good f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb
>> # bad: [2d0e30c30f84d08dc16f0f2af41f1b8a85f0755e] bpf: add helper for
>> retrieving current numa node id
>> git bisect bad 2d0e30c30f84d08dc16f0f2af41f1b8a85f0755e
>> # bad: [a10b91b8b81c29b87ff5a6d58c1402898337b956] Merge branch 'udpmem'
>> git bisect bad a10b91b8b81c29b87ff5a6d58c1402898337b956
>> # good: [850cbaddb52dfd4e0c7cabe2c168dd34b44ae0b9] udp: use it's own
>> memory accounting schema
>> git bisect good 850cbaddb52dfd4e0c7cabe2c168dd34b44ae0b9
>> # first bad commit: [a10b91b8b81c29b87ff5a6d58c1402898337b956] Merge
>> branch 'udpmem'
>>
>>
>> [ 112.472363] BUG: unable to handle kernel NULL pointer dereference
>> at (null)
>> [ 112.473360] IP: [<ffffffffb76f8031>] __sk_mem_raise_allocated+0x31/0x3f0
>> [ 112.474156] PGD 62a08067 [ 112.474455] PUD 2b8bf067
>> PMD 0 [ 112.474856]
>> [ 112.475054] Oops: 0002 [#1] SMP
>> [ 112.475431] Modules linked in: nf_conntrack_netlink udp_diag
>> tcp_diag inet_diag netlink_diag af_packet_diag unix_diag binfmt_misc
>> nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
>> xt_conntrack nf_conntrack nfnetlink ip6table_filter ip6_tables ppdev
>> sunrpc crc32c_intel joydev virtio_balloon virtio_net i2c_piix4
>> parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core tpm virtio_blk
>> serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
>> [ 112.480594] CPU: 1 PID: 7405 Comm: socket_udplite Not tainted 4.8.0+ #84
>> [ 112.481377] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS 1.9.1-1.fc24 04/01/2014
>> [ 112.482375] task: ffff928a5b5fa540 task.stack: ffffb3b484a0c000
>> [ 112.483059] RIP: 0010:[<ffffffffb76f8031>] [<ffffffffb76f8031>]
>> __sk_mem_raise_allocated+0x31/0x3f0
>> [ 112.484135] RSP: 0018:ffff928abfd03b18 EFLAGS: 00010296
>> [ 112.484758] RAX: 0000000000000001 RBX: ffff928aa293cfc0 RCX: 0000000000000001
>> [ 112.485585] RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff928aa293cfc0
>> [ 112.486414] RBP: ffff928abfd03b48 R08: 0de4c53600000000 R09: 0000000000000000
>> [ 112.487241] R10: 000000006226b971 R11: 0000000000000000 R12: ffff928aa293cfc0
>> [ 112.488064] R13: 0000000000000001 R14: ffffffffb7f0d5a0 R15: 0000000000001000
>> [ 112.488893] FS: 00007f058067a700(0000) GS:ffff928abfd00000(0000)
>> knlGS:0000000000000000
>> [ 112.489807] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 112.490447] CR2: 0000000000000000 CR3: 000000002b8f5000 CR4: 00000000000006e0
>> [ 112.491248] DR0: 00000000000100a0 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 112.492025] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>> [ 112.492808] Stack:
>> [ 112.493038] 0000000100000300 ffff928aa293cfc0 ffff928a651b9c00
>> 0000000000000300
>> [ 112.493912] ffff928aa293d108 0000000000001000 ffff928abfd03b88
>> ffffffffb779e094
>> [ 112.494782] ffff928abfd03b70 ffff928a651b9c00 ffff928aa293cfc0
>> 0000000000000000
>
> Thanks for the report.
>
> I guess following patch would be needed ?
Yes, you are right. It works if we set .memory_allocated and .sysctl_mem.
Thanks,
Andrei
>
> diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
> index af817158d830c0da080935ba29e012dffbb89112..12604c0371c451efcc9aad278bb86be9ac4bb813 100644
> --- a/net/ipv4/udplite.c
> +++ b/net/ipv4/udplite.c
> @@ -54,6 +54,7 @@ struct proto udplite_prot = {
> .hash = udp_lib_hash,
> .unhash = udp_lib_unhash,
> .get_port = udp_v4_get_port,
> + .memory_allocated = &udp_memory_allocated,
> .obj_size = sizeof(struct udp_sock),
> .h.udp_table = &udplite_table,
> #ifdef CONFIG_COMPAT
> diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
> index 47d0d2b87106558fece3496479198005c55b99e7..946025c888cc9519fb3523edbbe8afbb18273326 100644
> --- a/net/ipv6/udplite.c
> +++ b/net/ipv6/udplite.c
> @@ -49,6 +49,7 @@ struct proto udplitev6_prot = {
> .hash = udp_lib_hash,
> .unhash = udp_lib_unhash,
> .get_port = udp_v6_get_port,
> + .memory_allocated = &udp_memory_allocated,
> .obj_size = sizeof(struct udp6_sock),
> .h.udp_table = &udplite_table,
> #ifdef CONFIG_COMPAT
>
>
^ permalink raw reply
* Re: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
From: Nick Kralevich @ 2016-11-14 23:58 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux
In-Reply-To: <1479145685-4899-1-git-send-email-sds@tycho.nsa.gov>
On Mon, Nov 14, 2016 at 9:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> The combining logic for dontaudit rules was wrong, causing
> a dontaudit A B:C *; rule to be clobbered by a dontaudit A B:C p;
> rule.
>
> Reported-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> libsepol/src/expand.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
> index 004a029..d7adbf8 100644
> --- a/libsepol/src/expand.c
> +++ b/libsepol/src/expand.c
> @@ -1604,7 +1604,8 @@ static int expand_range_trans(expand_state_t * state,
> static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> avtab_t * avtab, avtab_key_t * key,
> cond_av_list_t ** cond,
> - av_extended_perms_t *xperms)
> + av_extended_perms_t *xperms,
> + char *alloced)
> {
> avtab_ptr_t node;
For robustness, it would be safer to ensure that alloced was always
assigned to. This variable may end up unassigned on certain error
conditions. It's not a bug today, since the caller always performs a
check on the return value prior to using this variable, but it could
be a use of an unassigned variable in a future version of this code.
Also, "bool" would be a better type for alloced, rather than using a "char"....
> avtab_datum_t avdatum;
> @@ -1658,6 +1659,11 @@ static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> nl->next = *cond;
> *cond = nl;
> }
> + if (alloced)
> + *alloced = 1;
> + } else {
> + if (alloced)
> + *alloced = 0;
> }
>
> return node;
> @@ -1750,7 +1756,7 @@ static int expand_terule_helper(sepol_handle_t * handle,
> return EXPAND_RULE_CONFLICT;
> }
>
> - node = find_avtab_node(handle, avtab, &avkey, cond, NULL);
> + node = find_avtab_node(handle, avtab, &avkey, cond, NULL, NULL);
> if (!node)
> return -1;
> if (enabled) {
> @@ -1790,6 +1796,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> class_perm_node_t *cur;
> uint32_t spec = 0;
> unsigned int i;
> + char alloced;
>
> if (specified & AVRULE_ALLOWED) {
> spec = AVTAB_ALLOWED;
> @@ -1824,7 +1831,8 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> avkey.target_class = cur->tclass;
> avkey.specified = spec;
>
> - node = find_avtab_node(handle, avtab, &avkey, cond, extended_perms);
> + node = find_avtab_node(handle, avtab, &avkey, cond,
> + extended_perms, &alloced);
> if (!node)
> return EXPAND_RULE_ERROR;
> if (enabled) {
> @@ -1850,7 +1858,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> */
> avdatump->data &= cur->data;
> } else if (specified & AVRULE_DONTAUDIT) {
> - if (avdatump->data)
> + if (!alloced)
> avdatump->data &= ~cur->data;
> else
> avdatump->data = ~cur->data;
> --
> 2.7.4
>
--
Nick Kralevich | Android Security | nnk@google.com | 650.214.4037
^ permalink raw reply
* Re: [PATCH v12 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-14 23:58 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <1479138156-28905-12-git-send-email-kwankhede@nvidia.com>
On Mon, 14 Nov 2016 21:12:25 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Notifier should be registered, if external user wants to use
> vfio_pin_pages()/vfio_unpin_pages() APIs to pin/unpin pages.
> Vendor driver should use VFIO_IOMMU_NOTIFY_DMA_UNMAP action to invalidate
> mappings.
>
> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> Signed-off-by: Neo Jia <cjia@nvidia.com>
> Change-Id: I5910d0024d6be87f3e8d3e0ca0eaeaaa0b17f271
> ---
> drivers/vfio/vfio.c | 73 +++++++++++++++++++++++++++++++++++++++++
> drivers/vfio/vfio_iommu_type1.c | 60 ++++++++++++++++++++++++++-------
> include/linux/vfio.h | 11 +++++++
> 3 files changed, 132 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 7dcfbca2016a..388a3cbddbd9 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1902,6 +1902,79 @@ err_unpin_pages:
> }
> EXPORT_SYMBOL(vfio_unpin_pages);
>
> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_register_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->register_notifier))
> + ret = driver->ops->register_notifier(container->iommu_data, nb);
> + else
> + ret = -ENOTTY;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_register_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_register_notifier);
> +
> +int vfio_unregister_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unregister_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unregister_notifier))
> + ret = driver->ops->unregister_notifier(container->iommu_data,
> + nb);
> + else
> + ret = -ENOTTY;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unregister_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unregister_notifier);
> +
> /**
> * Module/class support
> */
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 2697d874dd35..7e034e7c5ea5 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -38,6 +38,7 @@
> #include <linux/workqueue.h>
> #include <linux/pid_namespace.h>
> #include <linux/mdev.h>
> +#include <linux/notifier.h>
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
> @@ -60,6 +61,7 @@ struct vfio_iommu {
> struct vfio_domain *external_domain; /* domain for external user */
> struct mutex lock;
> struct rb_root dma_list;
> + struct blocking_notifier_head notifier;
> bool v2;
> bool nesting;
> };
> @@ -568,7 +570,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>
> mutex_lock(&iommu->lock);
>
> - if (!iommu->external_domain) {
> + /* Fail if notifier list is empty */
> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> ret = -EINVAL;
> goto pin_done;
> }
> @@ -854,15 +857,29 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
> if (dma->task->mm != current->mm)
> break;
> unmapped += dma->size;
> +
> + mutex_unlock(&iommu->lock);
> + if (iommu->external_domain && !RB_EMPTY_ROOT(&dma->pfn_list)) {
> + struct vfio_iommu_type1_dma_unmap nb_unmap;
> +
> + nb_unmap.iova = dma->iova;
> + nb_unmap.size = dma->size;
> + blocking_notifier_call_chain(&iommu->notifier,
> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> + &nb_unmap);
> +
> + if (WARN_ON(!RB_EMPTY_ROOT(&dma->pfn_list)))
> + goto unmap_exit;
> + }
> + mutex_lock(&iommu->lock);
Why are the mutexes pushed out so far, we are referencing way too much
stuff outside of the mutex here. The notifier head has its own
semaphore, so we should be able to squeeze the mutex opening to just
around the notifier call, in which case we only worry about the iommu
itself going way.
> vfio_remove_dma(iommu, dma);
> }
>
> unlock:
> mutex_unlock(&iommu->lock);
> -
> +unmap_exit:
> /* Report how much was unmapped */
> unmap->size = unmapped;
> -
Stray line deletions.
> return ret;
> }
>
> @@ -1430,6 +1447,7 @@ static void *vfio_iommu_type1_open(unsigned long arg)
> INIT_LIST_HEAD(&iommu->domain_list);
> iommu->dma_list = RB_ROOT;
> mutex_init(&iommu->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&iommu->notifier);
>
> return iommu;
> }
> @@ -1565,16 +1583,34 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
> return -ENOTTY;
> }
>
> +static int vfio_iommu_type1_register_notifier(void *iommu_data,
> + struct notifier_block *nb)
> +{
> + struct vfio_iommu *iommu = iommu_data;
> +
> + return blocking_notifier_chain_register(&iommu->notifier, nb);
> +}
> +
> +static int vfio_iommu_type1_unregister_notifier(void *iommu_data,
> + struct notifier_block *nb)
> +{
> + struct vfio_iommu *iommu = iommu_data;
> +
> + return blocking_notifier_chain_unregister(&iommu->notifier, nb);
> +}
> +
> static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
> - .name = "vfio-iommu-type1",
> - .owner = THIS_MODULE,
> - .open = vfio_iommu_type1_open,
> - .release = vfio_iommu_type1_release,
> - .ioctl = vfio_iommu_type1_ioctl,
> - .attach_group = vfio_iommu_type1_attach_group,
> - .detach_group = vfio_iommu_type1_detach_group,
> - .pin_pages = vfio_iommu_type1_pin_pages,
> - .unpin_pages = vfio_iommu_type1_unpin_pages,
> + .name = "vfio-iommu-type1",
> + .owner = THIS_MODULE,
> + .open = vfio_iommu_type1_open,
> + .release = vfio_iommu_type1_release,
> + .ioctl = vfio_iommu_type1_ioctl,
> + .attach_group = vfio_iommu_type1_attach_group,
> + .detach_group = vfio_iommu_type1_detach_group,
> + .pin_pages = vfio_iommu_type1_pin_pages,
> + .unpin_pages = vfio_iommu_type1_unpin_pages,
> + .register_notifier = vfio_iommu_type1_register_notifier,
> + .unregister_notifier = vfio_iommu_type1_unregister_notifier,
> };
>
> static int __init vfio_iommu_type1_init(void)
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 86f507d0f585..123e089388e9 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -80,6 +80,10 @@ struct vfio_iommu_driver_ops {
> unsigned long *phys_pfn);
> int (*unpin_pages)(void *iommu_data,
> unsigned long *user_pfn, int npage);
> + int (*register_notifier)(void *iommu_data,
> + struct notifier_block *nb);
> + int (*unregister_notifier)(void *iommu_data,
> + struct notifier_block *nb);
> };
>
> extern int vfio_register_iommu_driver(const struct vfio_iommu_driver_ops *ops);
> @@ -137,6 +141,13 @@ extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn,
> int npage);
>
> +#define VFIO_IOMMU_NOTIFY_DMA_UNMAP 1
> +
> +extern int vfio_register_notifier(struct device *dev,
> + struct notifier_block *nb);
> +
> +extern int vfio_unregister_notifier(struct device *dev,
> + struct notifier_block *nb);
> /*
> * IRQfd - generic
> */
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v12 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-14 23:58 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <1479138156-28905-12-git-send-email-kwankhede@nvidia.com>
On Mon, 14 Nov 2016 21:12:25 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Notifier should be registered, if external user wants to use
> vfio_pin_pages()/vfio_unpin_pages() APIs to pin/unpin pages.
> Vendor driver should use VFIO_IOMMU_NOTIFY_DMA_UNMAP action to invalidate
> mappings.
>
> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> Signed-off-by: Neo Jia <cjia@nvidia.com>
> Change-Id: I5910d0024d6be87f3e8d3e0ca0eaeaaa0b17f271
> ---
> drivers/vfio/vfio.c | 73 +++++++++++++++++++++++++++++++++++++++++
> drivers/vfio/vfio_iommu_type1.c | 60 ++++++++++++++++++++++++++-------
> include/linux/vfio.h | 11 +++++++
> 3 files changed, 132 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 7dcfbca2016a..388a3cbddbd9 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1902,6 +1902,79 @@ err_unpin_pages:
> }
> EXPORT_SYMBOL(vfio_unpin_pages);
>
> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_register_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->register_notifier))
> + ret = driver->ops->register_notifier(container->iommu_data, nb);
> + else
> + ret = -ENOTTY;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_register_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_register_notifier);
> +
> +int vfio_unregister_notifier(struct device *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !nb)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unregister_nb;
> +
> + container = group->container;
> + down_read(&container->group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unregister_notifier))
> + ret = driver->ops->unregister_notifier(container->iommu_data,
> + nb);
> + else
> + ret = -ENOTTY;
> +
> + up_read(&container->group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unregister_nb:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unregister_notifier);
> +
> /**
> * Module/class support
> */
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 2697d874dd35..7e034e7c5ea5 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -38,6 +38,7 @@
> #include <linux/workqueue.h>
> #include <linux/pid_namespace.h>
> #include <linux/mdev.h>
> +#include <linux/notifier.h>
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
> @@ -60,6 +61,7 @@ struct vfio_iommu {
> struct vfio_domain *external_domain; /* domain for external user */
> struct mutex lock;
> struct rb_root dma_list;
> + struct blocking_notifier_head notifier;
> bool v2;
> bool nesting;
> };
> @@ -568,7 +570,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>
> mutex_lock(&iommu->lock);
>
> - if (!iommu->external_domain) {
> + /* Fail if notifier list is empty */
> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> ret = -EINVAL;
> goto pin_done;
> }
> @@ -854,15 +857,29 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
> if (dma->task->mm != current->mm)
> break;
> unmapped += dma->size;
> +
> + mutex_unlock(&iommu->lock);
> + if (iommu->external_domain && !RB_EMPTY_ROOT(&dma->pfn_list)) {
> + struct vfio_iommu_type1_dma_unmap nb_unmap;
> +
> + nb_unmap.iova = dma->iova;
> + nb_unmap.size = dma->size;
> + blocking_notifier_call_chain(&iommu->notifier,
> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> + &nb_unmap);
> +
> + if (WARN_ON(!RB_EMPTY_ROOT(&dma->pfn_list)))
> + goto unmap_exit;
> + }
> + mutex_lock(&iommu->lock);
Why are the mutexes pushed out so far, we are referencing way too much
stuff outside of the mutex here. The notifier head has its own
semaphore, so we should be able to squeeze the mutex opening to just
around the notifier call, in which case we only worry about the iommu
itself going way.
> vfio_remove_dma(iommu, dma);
> }
>
> unlock:
> mutex_unlock(&iommu->lock);
> -
> +unmap_exit:
> /* Report how much was unmapped */
> unmap->size = unmapped;
> -
Stray line deletions.
> return ret;
> }
>
> @@ -1430,6 +1447,7 @@ static void *vfio_iommu_type1_open(unsigned long arg)
> INIT_LIST_HEAD(&iommu->domain_list);
> iommu->dma_list = RB_ROOT;
> mutex_init(&iommu->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&iommu->notifier);
>
> return iommu;
> }
> @@ -1565,16 +1583,34 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
> return -ENOTTY;
> }
>
> +static int vfio_iommu_type1_register_notifier(void *iommu_data,
> + struct notifier_block *nb)
> +{
> + struct vfio_iommu *iommu = iommu_data;
> +
> + return blocking_notifier_chain_register(&iommu->notifier, nb);
> +}
> +
> +static int vfio_iommu_type1_unregister_notifier(void *iommu_data,
> + struct notifier_block *nb)
> +{
> + struct vfio_iommu *iommu = iommu_data;
> +
> + return blocking_notifier_chain_unregister(&iommu->notifier, nb);
> +}
> +
> static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
> - .name = "vfio-iommu-type1",
> - .owner = THIS_MODULE,
> - .open = vfio_iommu_type1_open,
> - .release = vfio_iommu_type1_release,
> - .ioctl = vfio_iommu_type1_ioctl,
> - .attach_group = vfio_iommu_type1_attach_group,
> - .detach_group = vfio_iommu_type1_detach_group,
> - .pin_pages = vfio_iommu_type1_pin_pages,
> - .unpin_pages = vfio_iommu_type1_unpin_pages,
> + .name = "vfio-iommu-type1",
> + .owner = THIS_MODULE,
> + .open = vfio_iommu_type1_open,
> + .release = vfio_iommu_type1_release,
> + .ioctl = vfio_iommu_type1_ioctl,
> + .attach_group = vfio_iommu_type1_attach_group,
> + .detach_group = vfio_iommu_type1_detach_group,
> + .pin_pages = vfio_iommu_type1_pin_pages,
> + .unpin_pages = vfio_iommu_type1_unpin_pages,
> + .register_notifier = vfio_iommu_type1_register_notifier,
> + .unregister_notifier = vfio_iommu_type1_unregister_notifier,
> };
>
> static int __init vfio_iommu_type1_init(void)
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 86f507d0f585..123e089388e9 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -80,6 +80,10 @@ struct vfio_iommu_driver_ops {
> unsigned long *phys_pfn);
> int (*unpin_pages)(void *iommu_data,
> unsigned long *user_pfn, int npage);
> + int (*register_notifier)(void *iommu_data,
> + struct notifier_block *nb);
> + int (*unregister_notifier)(void *iommu_data,
> + struct notifier_block *nb);
> };
>
> extern int vfio_register_iommu_driver(const struct vfio_iommu_driver_ops *ops);
> @@ -137,6 +141,13 @@ extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn,
> int npage);
>
> +#define VFIO_IOMMU_NOTIFY_DMA_UNMAP 1
> +
> +extern int vfio_register_notifier(struct device *dev,
> + struct notifier_block *nb);
> +
> +extern int vfio_unregister_notifier(struct device *dev,
> + struct notifier_block *nb);
> /*
> * IRQfd - generic
> */
^ permalink raw reply
* [PATCH] vfs: fix boolreturn.cocci warnings
From: kbuild test robot @ 2016-11-14 23:58 UTC (permalink / raw)
To: Ian Kent
Cc: kbuild-all, Andrew Morton, Linux Memory Management List,
Alexander Viro, linux-fsdevel, linux-kernel
In-Reply-To: <201611150731.dUsDxUoh%fengguang.wu@intel.com>
fs/namespace.c:1185:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint' with return type bool
fs/namespace.c:1199:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint_rcu' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: Ian Kent <ikent@redhat.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
namespace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1182,7 +1182,7 @@ bool path_is_mountpoint(struct path *pat
bool res;
if (!d_mountpoint(path->dentry))
- return 0;
+ return false;
rcu_read_lock();
res = __path_is_mountpoint(path);
@@ -1196,7 +1196,7 @@ EXPORT_SYMBOL(path_is_mountpoint);
bool path_is_mountpoint_rcu(struct path *path)
{
if (!d_mountpoint(path->dentry))
- return 0;
+ return false;
return __path_is_mountpoint(path);
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Discussion on IPMI provider libraries
From: Brendan Higgins @ 2016-11-14 23:59 UTC (permalink / raw)
To: tomjose; +Cc: OpenBMC Maillist
In-Reply-To: <5821A449.3020807@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
>
> From what i have noticed in the patch, there is support for
> ipmid_callback_t handlers as it is now. So the change in API is to
> accommodate the OEM group ?
> So do you have plans to change the callback signatures for the standard
> commands already implemented in host-ipmid?
The support for ipmid_callback_t is only for backwards compatibility. Part
of the change in the API was to accommodate OEM/Group extensions, yes;
however, the intention is also to provide a cleaner API in general.
The privilege provided by each command is a registration parameter and it
> is consumed only by net-ipmid.
That's fine, but in that case it should not go in the callback; it should
be maintained and enforced by net-ipmid when it looks up a handler.
Cheers
[-- Attachment #2: Type: text/html, Size: 1344 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Salvator-X: Add GPIO keys support
From: Laurent Pinchart @ 2016-11-14 23:59 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Laurent Pinchart, Linux-Renesas, Kieran Bingham
In-Reply-To: <CAMuHMdWbXFBz2PpyGsgZNEPV50JYmZFfhw4hCVOpCviOUyct7g@mail.gmail.com>
Hi Geert,
On Monday 14 Nov 2016 20:47:03 Geert Uytterhoeven wrote:
> On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
> >> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
> >>> On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
> >>>> The main reason I haven't sent out a similar series yet is because the
> >>>> GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
> >>>> each of them, you have to choose at DT time if you want to use them as
> >>>> buttons or as LEDs.
> >>>>
> >>>> On ULCB, the same issue is present. For those, we settled on 1 key and
> >>>> 2 LEDs...
> >>>>
> >>>> Looking forward to more comments...
> >>>
> >>> In theory the GPIOs could be shared by the gpio-keys and LED drivers in
> >>> open- drain mode. I'm not sure the GPIO subsystem supports that though.
> >>
> >> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
> >> output (LEDs)". The result wasn't pretty...
> >
> > Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the
> > GPIO driver in case it can't read the value of GPIOs configured as output
> > in open- drain mode. If didn't shoot the idea down.
>
> If I'm not mistaken, the R-Car GPIO block does not support open-drain GPIO.
Not as such, but we can switch between input and output low, which is
basically open-drain.
> Even if it would support it, you cannot read the GPIO while actively
> pulling it down.
When actively driving it low you know the value is 0. Only when driving it
open do you need to read the value back, and that's easily implemented as the
hardware will be configured in input mode then.
> Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
> through switching between pulling down and not pulling down (or between
> output and input, which is what I did).
No, if you want to use both, you should configure the I/O in open-drain, in
which case you have two options:
- Turn the LED on by driving the I/O "high", meaning leaving it floating. The
pull-up resistor will turn the MOSFET on, the LED will be lit. When the
corresponding button is pressed the I/O will be connected to GND, turning the
LED off, and signalling the input.
- Turn the LED off by driving the I/O low. Pressing the button won't have any
effect. We need in this case to ignore the input value, which could be done by
disabling the I/O interrupt (or just ignoring it).
> Apart from that, there's also the discrepancy between hardware description
> (the GPIO is connected to both buttons and LEDs, hence it should be
> described that way in DT)
Correct, this is where a framework change is needed if we want to allow both
the GPIO keyboard and LED drivers to request the GPIO.
> and user policy (the user wants to use e.g. the first GPIO as a button, and
> the second GPIO as an LED).
That's easy to do, the user will just need to turn the first LED on, allowing
full button operation on the I/O.
> If you have ideas to solve these 2 issues, I'm happy to hear your
> thoughts!
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [linux-next:master 5439/5763] fs/namespace.c:1185:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint' with return type bool
From: kbuild test robot @ 2016-11-14 23:58 UTC (permalink / raw)
To: Ian Kent; +Cc: kbuild-all, Andrew Morton, Linux Memory Management List
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: b60de3eba5c3cf3a230c121def7c57aafa72c4f8
commit: 5910290273fdaf6dc1f6e8d4afdee5c5608b2b69 [5439/5763] vfs: add path_is_mountpoint() helper
coccinelle warnings: (new ones prefixed by >>)
>> fs/namespace.c:1185:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint' with return type bool
>> fs/namespace.c:1199:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint_rcu' with return type bool
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 04/21] tests: add hbitmap iter test
From: John Snow @ 2016-11-14 23:59 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-block, qemu-devel
Cc: kwolf, famz, armbru, mreitz, stefanha, pbonzini, den
In-Reply-To: <1478715476-132280-5-git-send-email-vsementsov@virtuozzo.com>
On 11/09/2016 01:17 PM, Vladimir Sementsov-Ogievskiy wrote:
> Test that hbitmap iter is resistant to bitmap resetting.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
> ---
> tests/test-hbitmap.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/tests/test-hbitmap.c b/tests/test-hbitmap.c
> index 9b7495c..c76d2b5 100644
> --- a/tests/test-hbitmap.c
> +++ b/tests/test-hbitmap.c
> @@ -898,6 +898,22 @@ static void hbitmap_test_add(const char *testpath,
> hbitmap_test_teardown);
> }
>
> +static void test_hbitmap_iter_and_reset(TestHBitmapData *data,
> + const void *unused)
> +{
> + HBitmapIter hbi;
> +
> + hbitmap_test_init(data, L1 * 2, 0);
> + hbitmap_set(data->hb, 0, data->size);
> +
> + hbitmap_iter_init(&hbi, data->hb, BITS_PER_LONG - 1);
> +
> + hbitmap_iter_next(&hbi);
> +
> + hbitmap_reset_all(data->hb);
> + hbitmap_iter_next(&hbi);
> +}
> +
> int main(int argc, char **argv)
> {
> g_test_init(&argc, &argv, NULL);
> @@ -955,6 +971,9 @@ int main(int argc, char **argv)
> test_hbitmap_serialize_part);
> hbitmap_test_add("/hbitmap/serialize/zeroes",
> test_hbitmap_serialize_zeroes);
> +
> + hbitmap_test_add("/hbitmap/iter/iter_and_reset",
> + test_hbitmap_iter_and_reset);
> g_test_run();
>
> return 0;
>
--
—js
^ permalink raw reply
* [PATCH] vfs: fix boolreturn.cocci warnings
From: kbuild test robot @ 2016-11-14 23:58 UTC (permalink / raw)
To: Ian Kent
Cc: kbuild-all, Andrew Morton, Linux Memory Management List,
Alexander Viro, linux-fsdevel, linux-kernel
In-Reply-To: <201611150731.dUsDxUoh%fengguang.wu@intel.com>
fs/namespace.c:1185:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint' with return type bool
fs/namespace.c:1199:9-10: WARNING: return of 0/1 in function 'path_is_mountpoint_rcu' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: Ian Kent <ikent@redhat.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
namespace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1182,7 +1182,7 @@ bool path_is_mountpoint(struct path *pat
bool res;
if (!d_mountpoint(path->dentry))
- return 0;
+ return false;
rcu_read_lock();
res = __path_is_mountpoint(path);
@@ -1196,7 +1196,7 @@ EXPORT_SYMBOL(path_is_mountpoint);
bool path_is_mountpoint_rcu(struct path *path)
{
if (!d_mountpoint(path->dentry))
- return 0;
+ return false;
return __path_is_mountpoint(path);
}
^ 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.