* [PATCH AUTOSEL 4.19 166/252] bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Daniel Borkmann, Sasha Levin, netdev, bpf
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 0a29275b6300f39f78a87f2038bbfe5bdbaeca47 ]
A negative value should be returned if map->map_type is invalid
although that is impossible now, but if we run into such situation
in future, then xdpbuff could be leaked.
Daniel Borkmann suggested:
-EBADRQC should be returned to stay consistent with generic XDP
for the tracepoint output and not to be confused with -EOPNOTSUPP
from other locations like dev_map_enqueue() when ndo_xdp_xmit is
missing and such.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/1578618277-18085-1-git-send-email-lirongqing@baidu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 9daf1a4118b51..40b3af05c883c 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3207,7 +3207,7 @@ static int __bpf_tx_xdp_map(struct net_device *dev_rx, void *fwd,
return err;
}
default:
- break;
+ return -EBADRQC;
}
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 169/252] drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ben Skeggs, Sasha Levin, dri-devel, nouveau
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Ben Skeggs <bskeggs@redhat.com>
[ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ]
Method init is typically ordered by class in the FW image as ThreeD,
TwoD, Compute.
Due to a bug in parsing the FW into our internal format, we've been
accidentally sending Twod + Compute methods to the ThreeD class, as
well as Compute methods to the TwoD class - oops.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 21 ++++++++++---------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
index 500cb08dd6080..b57ab5cea9a10 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c
@@ -143,23 +143,24 @@ gk20a_gr_av_to_method(struct gf100_gr *gr, const char *fw_name,
nent = (fuc.size / sizeof(struct gk20a_fw_av));
- pack = vzalloc((sizeof(*pack) * max_classes) +
- (sizeof(*init) * (nent + 1)));
+ pack = vzalloc((sizeof(*pack) * (max_classes + 1)) +
+ (sizeof(*init) * (nent + max_classes + 1)));
if (!pack) {
ret = -ENOMEM;
goto end;
}
- init = (void *)(pack + max_classes);
+ init = (void *)(pack + max_classes + 1);
- for (i = 0; i < nent; i++) {
- struct gf100_gr_init *ent = &init[i];
+ for (i = 0; i < nent; i++, init++) {
struct gk20a_fw_av *av = &((struct gk20a_fw_av *)fuc.data)[i];
u32 class = av->addr & 0xffff;
u32 addr = (av->addr & 0xffff0000) >> 14;
if (prevclass != class) {
- pack[classidx].init = ent;
+ if (prevclass) /* Add terminator to the method list. */
+ init++;
+ pack[classidx].init = init;
pack[classidx].type = class;
prevclass = class;
if (++classidx >= max_classes) {
@@ -169,10 +170,10 @@ gk20a_gr_av_to_method(struct gf100_gr *gr, const char *fw_name,
}
}
- ent->addr = addr;
- ent->data = av->data;
- ent->count = 1;
- ent->pitch = 1;
+ init->addr = addr;
+ init->data = av->data;
+ init->count = 1;
+ init->pitch = 1;
}
*ppack = pack;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 170/252] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Ben Skeggs, Sasha Levin, dri-devel, nouveau
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 412d49bc6e560..ba3883aed4567 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -157,7 +157,7 @@ nouveau_fence_wait_uevent_handler(struct nvif_notify *notify)
fence = list_entry(fctx->pending.next, typeof(*fence), head);
chan = rcu_dereference_protected(fence->channel, lockdep_is_held(&fctx->lock));
- if (nouveau_fence_update(fence->channel, fctx))
+ if (nouveau_fence_update(chan, fctx))
ret = NVIF_NOTIFY_DROP;
}
spin_unlock_irqrestore(&fctx->lock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Tony Lindgren @ 2020-02-14 17:03 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: alsa-devel, linux-omap, Kuninori Morimoto, Aaro Koskinen,
linux-kernel, Merlijn Wajer, Takashi Iwai, Liam Girdwood,
Mark Brown, Pavel Machek, Sebastian Reichel, Arthur D .,
Jarkko Nikula
In-Reply-To: <346dfd2b-23f8-87e0-6f45-27a5099b1066@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [200214 12:42]:
> Hi Tony,
>
> On 12/02/2020 16.35, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi@ti.com> [200212 08:02]:
> >>
> >>
> >> On 11/02/2020 19.16, Tony Lindgren wrote:
> >>> We can have multiple connections on a single McBSP instance configured
> >>> with audio graph card when using TDM (Time Division Multiplexing). Let's
> >>> allow that by configuring dais dynamically.
> >>
> >> It is still one DAI...
> >> If you have multiple codec connected to the same I2S lines, but the
> >> codecs communicate within different time slots, you still have one DAI
> >> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
> >
> > OK so subject should say "dodec DAIs" then I guess?
> >
> >>> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> >>> Documentation/devicetree/bindings/graph.txt for more details for
> >>> multiple endpoints.
> >>
> >> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
> >> The PCM3168a have 2 DAIs: playback and capture, but you can have
> >> multiple endpoints within a DAI.
> >
> > Yes this should follow the audio-graph-card.txt example. We end up with
> > mcbsp3 dts node as below on droid4:
> >
> > &mcbsp3 {
> > #sound-dai-cells = <0>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&mcbsp3_pins>;
> > status = "okay";
> >
> > ports {
> > mcbsp3_port: port@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > cpu_dai3: endpoint@0 {
> > reg = <0>;
> > dai-format = "dsp_a";
> > frame-master = <&cpcap_audio_codec1>;
> > bitclock-master = <&cpcap_audio_codec1>;
> > remote-endpoint = <&cpcap_audio_codec1>;
> > };
> >
> > cpu_dai_mdm: endpoint@1 {
> > reg = <1>;
> > dai-format = "dsp_a";
> > frame-master = <&cpcap_audio_codec1>;
> > bitclock-master = <&cpcap_audio_codec1>;
> > remote-endpoint = <&mot_mdm6600_audio_codec0>;
> > };
> > };
> > };
> > };
>
> According to
> Documentation/devicetree/bindings/sound/audio-graph-card.txt
> it should be something like this:
> &mcbsp3 {
> #sound-dai-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&mcbsp3_pins>;
> status = "okay";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
>
> cpu_dai3: endpoint@0 {
> dai-format = "dsp_a";
> frame-master = <&cpcap_audio_codec1>;
> bitclock-master = <&cpcap_audio_codec1>;
> remote-endpoint = <&cpcap_audio_codec1>;
> };
>
> cpu_dai_mdm: endpoint@1 {
> dai-format = "dsp_a";
> frame-master = <&cpcap_audio_codec1>;
> bitclock-master = <&cpcap_audio_codec1>;
> remote-endpoint = <&mot_mdm6600_audio_codec0>;
> };
> };
> };
> };
Hmms so I only spot reg use at different level changing above. Well
that's not according to Documentation/devicetree/bindings/graph.txt,
the reg numbering is per endpoint.
Sounds like the we have the example not following graph.txt in
Documentation/devicetree/bindings/sound/audio-graph-card.txt while
the code is now behaving as in graph.txt.
> If you span out dummy DAIs got dai1+ then how you will get anything
> working via endpoint1+?
> There will be no ops for McBSP, so it is not going to do anything...
Eventually it could have ops though. For things like capture of the tdm
slot data for recording audio call for example, I don't know how that's
supposed to work though. I guess mcbsp could be the clock master too,
and for those cases it would have ops.
But right now in droid4 voice call case mcbsp is just the i2s transport,
and everything happens betwee the modem and the cpcap pmic.
> > That is pretty much the same as the 'Multi DAI with DPCM' example, with
> > dne dai, and multiple endpoints. I think we still have just one port
> > for one i2s transport on the mcbsp :)
> >
> > Does the above look as what you would expect based on the binding?
>
> The audio-graph-card.txt example shows pcm3168a which have two DAIs,
> one for playback and one for capture.
>
> I guess Morimoto-san can explain if he carries out of tree patches to
> get the described setup working on top of mainline...
>
> But, no, based on the documentation I don't ;)
Sounds like audio-graph-card.txt is just out of sync with graph.txt
as we do have several working examples?
> >>> I've tested this with droid4 where cpcap pmic and modem voice are both
> >>> both wired to mcbsp3. I've also tested this on droid4 both with and
> >>> without the pending modem audio codec driver that is waiting for n_gsm
> >>> serdev dependencies to clear.
> >>
> >> What this patch you effectively just creating dummy-dais on top of the
> >> real McBSP DAI.
> >
> > Yes I think this is needed for snd-soc-audio-graph-card, and this allows
> > configuring whatever is needed for the i2s slot. But maybe you have some
> > better way of doing it in mind?
> >
> >> You also rename the DAIs, which might break ams-delta.
> >
> > Oops, that's not good. So should we just keep the old naming if there's
> > only one endpoint?
>
> That's an option, yes, if we really need extra dummy McBSP DAIs at all,
> again, let's hear from Morimoto-san or Mark.
Well it would not necessarily be a dummy mcbsp dai in all cases it seems
to me. But yeah nothing for the second dai to do right now for droid4
voice call as it's all between the modem and the pmic.
> >> We still have legacy support in
> >> omap-twl4030.c
> >> omap3pandora.c
> >> osk5912.c
> >> rx51.c
> >>
> >> which will break with the renamed DAI. On the other hand I think the
> >> legacy support can be dropped from them.
> >
> > I'm not sure what all that would take.
>
> For some it should not be a big deal as they only boot in DT mode.
> /me adds this to the TODO list.
OK
> >> I know it was discussed, but can not find the mail:
> >> Can you brief again on the audio connection?
> >
> > Below is a link to a mailing list thread where Sebastian describes
> > the audio connection:
> >
> > https://lkml.org/lkml/2018/3/28/881
>
> Thanks!
>
> >> Do you have branch with working code?
> >
> > Yeah I have slightly older set of the patches in my droid4-pending-v5.5
> > kernel.org git branch with voice calls working.
>
> I think I should put my droid4 out and try to get it working...
> Do you have a link for dummies to follow to get started? ;)
Probably the easiest one to use right now is the Maemo-leste devuan based
test image using v5.5 kernel + modem and audio patches:
https://leste.maemo.org/Motorola_Droid_4
Just use a decent speed micro-sd card rated "a1" for example.
Regards,
Tony
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [PATCH AUTOSEL 4.19 175/252] NFS: Revalidate the file size on a fatal write error
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Trond Myklebust, Trond Myklebust, Anna Schumaker, Sasha Levin,
linux-nfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Trond Myklebust <trondmy@gmail.com>
[ Upstream commit 0df68ced55443243951d02cc497be31fadf28173 ]
If we suffer a fatal error upon writing a file, which causes us to
need to revalidate the entire mapping, then we should also revalidate
the file size.
Fixes: d2ceb7e57086 ("NFS: Don't use page_file_mapping after removing the page")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/write.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index e27637fa0f790..e8152781814dd 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -240,7 +240,15 @@ static void nfs_grow_file(struct page *page, unsigned int offset, unsigned int c
/* A writeback failed: mark the page as bad, and invalidate the page cache */
static void nfs_set_pageerror(struct address_space *mapping)
{
+ struct inode *inode = mapping->host;
+
nfs_zap_mapping(mapping->host, mapping);
+ /* Force file size revalidation */
+ spin_lock(&inode->i_lock);
+ NFS_I(inode)->cache_validity |= NFS_INO_REVAL_FORCED |
+ NFS_INO_REVAL_PAGECACHE |
+ NFS_INO_INVALID_SIZE;
+ spin_unlock(&inode->i_lock);
}
/*
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 176/252] NFS/pnfs: Fix pnfs_generic_prepare_to_resend_writes()
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Trond Myklebust, Trond Myklebust, Anna Schumaker, Sasha Levin,
linux-nfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Trond Myklebust <trondmy@gmail.com>
[ Upstream commit 221203ce6406273cf00e5c6397257d986c003ee6 ]
Instead of making assumptions about the commit verifier contents, change
the commit code to ensure we always check that the verifier was set
by the XDR code.
Fixes: f54bcf2ecee9 ("pnfs: Prepare for flexfiles by pulling out common code")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/direct.c | 4 ++--
fs/nfs/nfs3xdr.c | 5 ++++-
fs/nfs/nfs4xdr.c | 5 ++++-
fs/nfs/pnfs_nfs.c | 7 +++----
fs/nfs/write.c | 4 +++-
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 29b70337dcd9f..c61bd3fc723ee 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -261,10 +261,10 @@ static int nfs_direct_cmp_commit_data_verf(struct nfs_direct_req *dreq,
data->ds_commit_index);
/* verifier not set so always fail */
- if (verfp->committed < 0)
+ if (verfp->committed < 0 || data->res.verf->committed <= NFS_UNSTABLE)
return 1;
- return nfs_direct_cmp_verf(verfp, &data->verf);
+ return nfs_direct_cmp_verf(verfp, data->res.verf);
}
/**
diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index 64e4fa33d89f0..9956453aa6ffc 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -2380,6 +2380,7 @@ static int nfs3_xdr_dec_commit3res(struct rpc_rqst *req,
void *data)
{
struct nfs_commitres *result = data;
+ struct nfs_writeverf *verf = result->verf;
enum nfs_stat status;
int error;
@@ -2392,7 +2393,9 @@ static int nfs3_xdr_dec_commit3res(struct rpc_rqst *req,
result->op_status = status;
if (status != NFS3_OK)
goto out_status;
- error = decode_writeverf3(xdr, &result->verf->verifier);
+ error = decode_writeverf3(xdr, &verf->verifier);
+ if (!error)
+ verf->committed = NFS_FILE_SYNC;
out:
return error;
out_status:
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 1c0227c78a7bc..c4cf0192d7bb8 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -4439,11 +4439,14 @@ static int decode_write_verifier(struct xdr_stream *xdr, struct nfs_write_verifi
static int decode_commit(struct xdr_stream *xdr, struct nfs_commitres *res)
{
+ struct nfs_writeverf *verf = res->verf;
int status;
status = decode_op_hdr(xdr, OP_COMMIT);
if (!status)
- status = decode_write_verifier(xdr, &res->verf->verifier);
+ status = decode_write_verifier(xdr, &verf->verifier);
+ if (!status)
+ verf->committed = NFS_FILE_SYNC;
return status;
}
diff --git a/fs/nfs/pnfs_nfs.c b/fs/nfs/pnfs_nfs.c
index d5e4d3cd8c7f1..acfb52bc0007d 100644
--- a/fs/nfs/pnfs_nfs.c
+++ b/fs/nfs/pnfs_nfs.c
@@ -30,12 +30,11 @@ EXPORT_SYMBOL_GPL(pnfs_generic_rw_release);
/* Fake up some data that will cause nfs_commit_release to retry the writes. */
void pnfs_generic_prepare_to_resend_writes(struct nfs_commit_data *data)
{
- struct nfs_page *first = nfs_list_entry(data->pages.next);
+ struct nfs_writeverf *verf = data->res.verf;
data->task.tk_status = 0;
- memcpy(&data->verf.verifier, &first->wb_verf,
- sizeof(data->verf.verifier));
- data->verf.verifier.data[0]++; /* ensure verifier mismatch */
+ memset(&verf->verifier, 0, sizeof(verf->verifier));
+ verf->committed = NFS_UNSTABLE;
}
EXPORT_SYMBOL_GPL(pnfs_generic_prepare_to_resend_writes);
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index e8152781814dd..ce1da8cbac003 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1814,6 +1814,7 @@ static void nfs_commit_done(struct rpc_task *task, void *calldata)
static void nfs_commit_release_pages(struct nfs_commit_data *data)
{
+ const struct nfs_writeverf *verf = data->res.verf;
struct nfs_page *req;
int status = data->task.tk_status;
struct nfs_commit_info cinfo;
@@ -1840,7 +1841,8 @@ static void nfs_commit_release_pages(struct nfs_commit_data *data)
/* Okay, COMMIT succeeded, apparently. Check the verifier
* returned by the server against all stored verfs. */
- if (!nfs_write_verifier_cmp(&req->wb_verf, &data->verf.verifier)) {
+ if (verf->committed > NFS_UNSTABLE &&
+ !nfs_write_verifier_cmp(&req->wb_verf, &verf->verifier)) {
/* We have a match */
if (req->wb_page)
nfs_inode_remove_request(req);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 177/252] iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Will Deacon, Jean-Philippe Brucker, Sasha Levin, linux-arm-kernel,
iommu
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Will Deacon <will@kernel.org>
[ Upstream commit d71e01716b3606a6648df7e5646ae12c75babde4 ]
If, for some bizarre reason, the compiler decided to split up the write
of STE DWORD 0, we could end up making a partial structure valid.
Although this probably won't happen, follow the example of the
context-descriptor code and use WRITE_ONCE() to ensure atomicity of the
write.
Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/arm-smmu-v3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index eff1f3aa5ef43..6b7664052b5be 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1185,7 +1185,8 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
}
arm_smmu_sync_ste_for_sid(smmu, sid);
- dst[0] = cpu_to_le64(val);
+ /* See comment in arm_smmu_write_ctx_desc() */
+ WRITE_ONCE(dst[0], cpu_to_le64(val));
arm_smmu_sync_ste_for_sid(smmu, sid);
/* It's likely that we'll want to use the new STE soon */
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 135/252] drm: remove the newline for CRC source name.
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dingchen Zhang, Leo Li, Harry Wentland, Sam Ravnborg,
Alex Deucher, Sasha Levin, dri-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Dingchen Zhang <dingchen.zhang@amd.com>
[ Upstream commit 72a848f5c46bab4c921edc9cbffd1ab273b2be17 ]
userspace may transfer a newline, and this terminating newline
is replaced by a '\0' to avoid followup issues.
'len-1' is the index to replace the newline of CRC source name.
v3: typo fix (Sam)
v2: update patch subject, body and format. (Sam)
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Dingchen Zhang <dingchen.zhang@amd.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610134751.14356-1-dingchen.zhang@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/drm_debugfs_crc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c
index c88e5ff41add6..a3c756710845e 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -101,8 +101,8 @@ static ssize_t crc_control_write(struct file *file, const char __user *ubuf,
if (IS_ERR(source))
return PTR_ERR(source);
- if (source[len] == '\n')
- source[len] = '\0';
+ if (source[len - 1] == '\n')
+ source[len - 1] = '\0';
spin_lock_irq(&crc->lock);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 178/252] f2fs: set I_LINKABLE early to avoid wrong access by vfs
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jaegeuk Kim, Sasha Levin, linux-f2fs-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Jaegeuk Kim <jaegeuk@kernel.org>
[ Upstream commit 5b1dbb082f196278f82b6a15a13848efacb9ff11 ]
This patch moves setting I_LINKABLE early in rename2(whiteout) to avoid the
below warning.
[ 3189.163385] WARNING: CPU: 3 PID: 59523 at fs/inode.c:358 inc_nlink+0x32/0x40
[ 3189.246979] Call Trace:
[ 3189.248707] f2fs_init_inode_metadata+0x2d6/0x440 [f2fs]
[ 3189.251399] f2fs_add_inline_entry+0x162/0x8c0 [f2fs]
[ 3189.254010] f2fs_add_dentry+0x69/0xe0 [f2fs]
[ 3189.256353] f2fs_do_add_link+0xc5/0x100 [f2fs]
[ 3189.258774] f2fs_rename2+0xabf/0x1010 [f2fs]
[ 3189.261079] vfs_rename+0x3f8/0xaa0
[ 3189.263056] ? tomoyo_path_rename+0x44/0x60
[ 3189.265283] ? do_renameat2+0x49b/0x550
[ 3189.267324] do_renameat2+0x49b/0x550
[ 3189.269316] __x64_sys_renameat2+0x20/0x30
[ 3189.271441] do_syscall_64+0x5a/0x230
[ 3189.273410] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 3189.275848] RIP: 0033:0x7f270b4d9a49
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/f2fs/namei.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 0ace2c2e3de93..4f0cc0c79d1ee 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -769,6 +769,7 @@ static int __f2fs_tmpfile(struct inode *dir, struct dentry *dentry,
if (whiteout) {
f2fs_i_links_write(inode, false);
+ inode->i_state |= I_LINKABLE;
*whiteout = inode;
} else {
d_tmpfile(dentry, inode);
@@ -835,6 +836,12 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
F2FS_I(old_dentry->d_inode)->i_projid)))
return -EXDEV;
+ if (flags & RENAME_WHITEOUT) {
+ err = f2fs_create_whiteout(old_dir, &whiteout);
+ if (err)
+ return err;
+ }
+
err = dquot_initialize(old_dir);
if (err)
goto out;
@@ -865,17 +872,11 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
}
}
- if (flags & RENAME_WHITEOUT) {
- err = f2fs_create_whiteout(old_dir, &whiteout);
- if (err)
- goto out_dir;
- }
-
if (new_inode) {
err = -ENOTEMPTY;
if (old_dir_entry && !f2fs_empty_dir(new_inode))
- goto out_whiteout;
+ goto out_dir;
err = -ENOENT;
new_entry = f2fs_find_entry(new_dir, &new_dentry->d_name,
@@ -883,7 +884,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
if (!new_entry) {
if (IS_ERR(new_page))
err = PTR_ERR(new_page);
- goto out_whiteout;
+ goto out_dir;
}
f2fs_balance_fs(sbi, true);
@@ -915,7 +916,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
err = f2fs_add_link(new_dentry, old_inode);
if (err) {
f2fs_unlock_op(sbi);
- goto out_whiteout;
+ goto out_dir;
}
if (old_dir_entry)
@@ -939,7 +940,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
if (IS_ERR(old_page))
err = PTR_ERR(old_page);
f2fs_unlock_op(sbi);
- goto out_whiteout;
+ goto out_dir;
}
}
}
@@ -958,7 +959,6 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
f2fs_delete_entry(old_entry, old_page, old_dir, NULL);
if (whiteout) {
- whiteout->i_state |= I_LINKABLE;
set_inode_flag(whiteout, FI_INC_LINK);
err = f2fs_add_link(old_dentry, whiteout);
if (err)
@@ -992,15 +992,14 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry,
f2fs_unlock_op(sbi);
if (new_page)
f2fs_put_page(new_page, 0);
-out_whiteout:
- if (whiteout)
- iput(whiteout);
out_dir:
if (old_dir_entry)
f2fs_put_page(old_dir_page, 0);
out_old:
f2fs_put_page(old_page, 0);
out:
+ if (whiteout)
+ iput(whiteout);
return err;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 136/252] drm/gma500: remove set but not used variables 'hist_reg'
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chen Zhou, Hulk Robot, Patrik Jakobsson, Sasha Levin, dri-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Chen Zhou <chenzhou10@huawei.com>
[ Upstream commit 72f775611daf3ce20358388facbaf11f22899fa2 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/psb_irq.c: In function psb_irq_turn_off_dpst:
drivers/gpu/drm/gma500/psb_irq.c:473:6:
warning: variable hist_reg set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191227114811.14907-1-chenzhou10@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/gma500/psb_irq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index f75f199c84311..518d7b4456bf1 100644
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -471,12 +471,11 @@ void psb_irq_turn_off_dpst(struct drm_device *dev)
{
struct drm_psb_private *dev_priv =
(struct drm_psb_private *) dev->dev_private;
- u32 hist_reg;
u32 pwm_reg;
if (gma_power_begin(dev, false)) {
PSB_WVDC32(0x00000000, HISTOGRAM_INT_CONTROL);
- hist_reg = PSB_RVDC32(HISTOGRAM_INT_CONTROL);
+ PSB_RVDC32(HISTOGRAM_INT_CONTROL);
psb_disable_pipestat(dev_priv, 0, PIPE_DPST_EVENT_ENABLE);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v7 14/15] bugreport: list contents of $OBJDIR/info
From: Junio C Hamano @ 2020-02-14 17:04 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git
In-Reply-To: <20200214015343.201946-15-emilyshaffer@google.com>
Emily Shaffer <emilyshaffer@google.com> writes:
> Miscellaneous information used about the object store can end up in
> .git/objects/info; this can help us understand what may be going on with
> the object store when the user is reporting a bug. Otherwise, it could
> be difficult to track down what is going wrong with an object which
> isn't kept locally to .git/objects/ or .git/objects/pack. Having some
> understanding of where the user's objects may be kept can save us some
> hops during the bug reporting process.
This step seems to have a new whitespace breakage that did not exist
in the previous round.
^ permalink raw reply
* [PATCH AUTOSEL 4.19 180/252] scsi: iscsi: Don't destroy session if there are outstanding connections
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nick Black, Salman Qazi, Junho Ryu, Khazhismel Kumykov,
Gabriel Krisman Bertazi, Lee Duncan, Martin K . Petersen,
Sasha Levin, open-iscsi, linux-scsi
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Nick Black <nlb@google.com>
[ Upstream commit 54155ed4199c7aa3fd20866648024ab63c96d579 ]
A faulty userspace that calls destroy_session() before destroying the
connections can trigger the failure. This patch prevents the issue by
refusing to destroy the session if there are outstanding connections.
------------[ cut here ]------------
kernel BUG at mm/slub.c:306!
invalid opcode: 0000 [#1] SMP PTI
CPU: 1 PID: 1224 Comm: iscsid Not tainted 5.4.0-rc2.iscsi+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:__slab_free+0x181/0x350
[...]
[ 1209.686056] RSP: 0018:ffffa93d4074fae0 EFLAGS: 00010246
[ 1209.686694] RAX: ffff934efa5ad800 RBX: 000000008010000a RCX: ffff934efa5ad800
[ 1209.687651] RDX: ffff934efa5ad800 RSI: ffffeb4041e96b00 RDI: ffff934efd402c40
[ 1209.688582] RBP: ffffa93d4074fb80 R08: 0000000000000001 R09: ffffffffbb5dfa26
[ 1209.689425] R10: ffff934efa5ad800 R11: 0000000000000001 R12: ffffeb4041e96b00
[ 1209.690285] R13: ffff934efa5ad800 R14: ffff934efd402c40 R15: 0000000000000000
[ 1209.691213] FS: 00007f7945dfb540(0000) GS:ffff934efda80000(0000) knlGS:0000000000000000
[ 1209.692316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1209.693013] CR2: 000055877fd3da80 CR3: 0000000077384000 CR4: 00000000000006e0
[ 1209.693897] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1209.694773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1209.695631] Call Trace:
[ 1209.695957] ? __wake_up_common_lock+0x8a/0xc0
[ 1209.696712] iscsi_pool_free+0x26/0x40
[ 1209.697263] iscsi_session_teardown+0x2f/0xf0
[ 1209.698117] iscsi_sw_tcp_session_destroy+0x45/0x60
[ 1209.698831] iscsi_if_rx+0xd88/0x14e0
[ 1209.699370] netlink_unicast+0x16f/0x200
[ 1209.699932] netlink_sendmsg+0x21a/0x3e0
[ 1209.700446] sock_sendmsg+0x4f/0x60
[ 1209.700902] ___sys_sendmsg+0x2ae/0x320
[ 1209.701451] ? cp_new_stat+0x150/0x180
[ 1209.701922] __sys_sendmsg+0x59/0xa0
[ 1209.702357] do_syscall_64+0x52/0x160
[ 1209.702812] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1209.703419] RIP: 0033:0x7f7946433914
[...]
[ 1209.706084] RSP: 002b:00007fffb99f2378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 1209.706994] RAX: ffffffffffffffda RBX: 000055bc869eac20 RCX: 00007f7946433914
[ 1209.708082] RDX: 0000000000000000 RSI: 00007fffb99f2390 RDI: 0000000000000005
[ 1209.709120] RBP: 00007fffb99f2390 R08: 000055bc84fe9320 R09: 00007fffb99f1f07
[ 1209.710110] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000038
[ 1209.711085] R13: 000055bc8502306e R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace a2d933ede7f730d8 ]---
Link: https://lore.kernel.org/r/20191226203148.2172200-1-krisman@collabora.com
Signed-off-by: Nick Black <nlb@google.com>
Co-developed-by: Salman Qazi <sqazi@google.com>
Signed-off-by: Salman Qazi <sqazi@google.com>
Co-developed-by: Junho Ryu <jayr@google.com>
Signed-off-by: Junho Ryu <jayr@google.com>
Co-developed-by: Khazhismel Kumykov <khazhy@google.com>
Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
Co-developed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/iscsi_tcp.c | 4 ++++
drivers/scsi/scsi_transport_iscsi.c | 26 +++++++++++++++++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 55181d28291e7..7212e3a13fe6b 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -892,6 +892,10 @@ iscsi_sw_tcp_session_create(struct iscsi_endpoint *ep, uint16_t cmds_max,
static void iscsi_sw_tcp_session_destroy(struct iscsi_cls_session *cls_session)
{
struct Scsi_Host *shost = iscsi_session_to_shost(cls_session);
+ struct iscsi_session *session = cls_session->dd_data;
+
+ if (WARN_ON_ONCE(session->leadconn))
+ return;
iscsi_tcp_r2tpool_free(cls_session->dd_data);
iscsi_session_teardown(cls_session);
diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
index 4c4781e5974f0..c0fb9e7890807 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2945,6 +2945,24 @@ iscsi_set_path(struct iscsi_transport *transport, struct iscsi_uevent *ev)
return err;
}
+static int iscsi_session_has_conns(int sid)
+{
+ struct iscsi_cls_conn *conn;
+ unsigned long flags;
+ int found = 0;
+
+ spin_lock_irqsave(&connlock, flags);
+ list_for_each_entry(conn, &connlist, conn_list) {
+ if (iscsi_conn_get_sid(conn) == sid) {
+ found = 1;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&connlock, flags);
+
+ return found;
+}
+
static int
iscsi_set_iface_params(struct iscsi_transport *transport,
struct iscsi_uevent *ev, uint32_t len)
@@ -3522,10 +3540,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
break;
case ISCSI_UEVENT_DESTROY_SESSION:
session = iscsi_session_lookup(ev->u.d_session.sid);
- if (session)
- transport->destroy_session(session);
- else
+ if (!session)
err = -EINVAL;
+ else if (iscsi_session_has_conns(ev->u.d_session.sid))
+ err = -EBUSY;
+ else
+ transport->destroy_session(session);
break;
case ISCSI_UEVENT_UNBIND_SESSION:
session = iscsi_session_lookup(ev->u.d_session.sid);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 183/252] RDMA/uverbs: Verify MR access flags
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael Guralnik, Yishai Hadas, Jason Gunthorpe, Sasha Levin,
linux-rdma
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Michael Guralnik <michaelgur@mellanox.com>
[ Upstream commit ca95c1411198c2d87217c19d44571052cdc94725 ]
Verify that MR access flags that are passed from user are all supported
ones, otherwise an error is returned.
Fixes: 4fca03778351 ("IB/uverbs: Move ib_access_flags and ib_read_counters_flags to uapi")
Link: https://lore.kernel.org/r/1578506740-22188-6-git-send-email-yishaih@mellanox.com
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/rdma/ib_verbs.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 54e4d1fd21f8f..874cd6e94093b 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -3864,6 +3864,9 @@ static inline int ib_check_mr_access(int flags)
!(flags & IB_ACCESS_LOCAL_WRITE))
return -EINVAL;
+ if (flags & ~IB_ACCESS_SUPPORTED)
+ return -EINVAL;
+
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 185/252] watchdog/softlockup: Enforce that timestamp is valid on boot
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Thomas Gleixner, Robert Richter, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 11e31f608b499f044f24b20be73f1dcab3e43f8a ]
Robert reported that during boot the watchdog timestamp is set to 0 for one
second which is the indicator for a watchdog reset.
The reason for this is that the timestamp is in seconds and the time is
taken from sched clock and divided by ~1e9. sched clock starts at 0 which
means that for the first second during boot the watchdog timestamp is 0,
i.e. reset.
Use ULONG_MAX as the reset indicator value so the watchdog works correctly
right from the start. ULONG_MAX would only conflict with a real timestamp
if the system reaches an uptime of 136 years on 32bit and almost eternity
on 64bit.
Reported-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/87o8v3uuzl.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/watchdog.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index bbc4940f21af6..6d60701dc6361 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -161,6 +161,8 @@ static void lockup_detector_update_enable(void)
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
+#define SOFTLOCKUP_RESET ULONG_MAX
+
/* Global variables, exported for sysctl */
unsigned int __read_mostly softlockup_panic =
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE;
@@ -267,7 +269,7 @@ notrace void touch_softlockup_watchdog_sched(void)
* Preemption can be enabled. It doesn't matter which CPU's timestamp
* gets zeroed here, so use the raw_ operation.
*/
- raw_cpu_write(watchdog_touch_ts, 0);
+ raw_cpu_write(watchdog_touch_ts, SOFTLOCKUP_RESET);
}
notrace void touch_softlockup_watchdog(void)
@@ -291,14 +293,14 @@ void touch_all_softlockup_watchdogs(void)
* the softlockup check.
*/
for_each_cpu(cpu, &watchdog_allowed_mask)
- per_cpu(watchdog_touch_ts, cpu) = 0;
+ per_cpu(watchdog_touch_ts, cpu) = SOFTLOCKUP_RESET;
wq_watchdog_touch(-1);
}
void touch_softlockup_watchdog_sync(void)
{
__this_cpu_write(softlockup_touch_sync, true);
- __this_cpu_write(watchdog_touch_ts, 0);
+ __this_cpu_write(watchdog_touch_ts, SOFTLOCKUP_RESET);
}
static int is_softlockup(unsigned long touch_ts)
@@ -376,7 +378,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
/* .. and repeat */
hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
- if (touch_ts == 0) {
+ if (touch_ts == SOFTLOCKUP_RESET) {
if (unlikely(__this_cpu_read(softlockup_touch_sync))) {
/*
* If the time stamp was touched atomically
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 184/252] IB/mlx4: Fix memory leak in add_gid error flow
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jack Morgenstein, Parav Pandit, Leon Romanovsky, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
[ Upstream commit eaad647e5cc27f7b46a27f3b85b14c4c8a64bffa ]
In procedure mlx4_ib_add_gid(), if the driver is unable to update the FW
gid table, there is a memory leak in the driver's copy of the gid table:
the gid entry's context buffer is not freed.
If such an error occurs, free the entry's context buffer, and mark the
entry as available (by setting its context pointer to NULL).
Fixes: e26be1bfef81 ("IB/mlx4: Implement ib_device callbacks")
Link: https://lore.kernel.org/r/20200115085050.73746-1-leon@kernel.org
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/mlx4/main.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 9386bb57b3d71..a19d3ad14dc37 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -246,6 +246,13 @@ static int mlx4_ib_update_gids(struct gid_entry *gids,
return mlx4_ib_update_gids_v1(gids, ibdev, port_num);
}
+static void free_gid_entry(struct gid_entry *entry)
+{
+ memset(&entry->gid, 0, sizeof(entry->gid));
+ kfree(entry->ctx);
+ entry->ctx = NULL;
+}
+
static int mlx4_ib_add_gid(const struct ib_gid_attr *attr, void **context)
{
struct mlx4_ib_dev *ibdev = to_mdev(attr->device);
@@ -306,6 +313,8 @@ static int mlx4_ib_add_gid(const struct ib_gid_attr *attr, void **context)
GFP_ATOMIC);
if (!gids) {
ret = -ENOMEM;
+ *context = NULL;
+ free_gid_entry(&port_gid_table->gids[free]);
} else {
for (i = 0; i < MLX4_MAX_PORT_GIDS; i++) {
memcpy(&gids[i].gid, &port_gid_table->gids[i].gid, sizeof(union ib_gid));
@@ -317,6 +326,12 @@ static int mlx4_ib_add_gid(const struct ib_gid_attr *attr, void **context)
if (!ret && hw_update) {
ret = mlx4_ib_update_gids(gids, ibdev, attr->port_num);
+ if (ret) {
+ spin_lock_bh(&iboe->lock);
+ *context = NULL;
+ free_gid_entry(&port_gid_table->gids[free]);
+ spin_unlock_bh(&iboe->lock);
+ }
kfree(gids);
}
@@ -346,10 +361,7 @@ static int mlx4_ib_del_gid(const struct ib_gid_attr *attr, void **context)
if (!ctx->refcount) {
unsigned int real_index = ctx->real_index;
- memset(&port_gid_table->gids[real_index].gid, 0,
- sizeof(port_gid_table->gids[real_index].gid));
- kfree(port_gid_table->gids[real_index].ctx);
- port_gid_table->gids[real_index].ctx = NULL;
+ free_gid_entry(&port_gid_table->gids[real_index]);
hw_update = 1;
}
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 186/252] ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hanjun Guo, Pankaj Bansal, Lorenzo Pieralisi, Will Deacon,
Sudeep Holla, Catalin Marinas, Robin Murphy, Sasha Levin,
linux-acpi, linux-arm-kernel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Hanjun Guo <guohanjun@huawei.com>
[ Upstream commit 3c23b83a88d00383e1d498cfa515249aa2fe0238 ]
The IORT specification [0] (Section 3, table 4, page 9) defines the
'Number of IDs' as 'The number of IDs in the range minus one'.
However, the IORT ID mapping function iort_id_map() treats the 'Number
of IDs' field as if it were the full IDs mapping count, with the
following check in place to detect out of boundary input IDs:
InputID >= Input base + Number of IDs
This check is flawed in that it considers the 'Number of IDs' field as
the full number of IDs mapping and disregards the 'minus one' from
the IDs count.
The correct check in iort_id_map() should be implemented as:
InputID > Input base + Number of IDs
this implements the specification correctly but unfortunately it breaks
existing firmwares that erroneously set the 'Number of IDs' as the full
IDs mapping count rather than IDs mapping count minus one.
e.g.
PCI hostbridge mapping entry 1:
Input base: 0x1000
ID Count: 0x100
Output base: 0x1000
Output reference: 0xC4 //ITS reference
PCI hostbridge mapping entry 2:
Input base: 0x1100
ID Count: 0x100
Output base: 0x2000
Output reference: 0xD4 //ITS reference
Two mapping entries which the second entry's Input base = the first
entry's Input base + ID count, so for InputID 0x1100 and with the
correct InputID check in place in iort_id_map() the kernel would map
the InputID to ITS 0xC4 not 0xD4 as it would be expected.
Therefore, to keep supporting existing flawed firmwares, introduce a
workaround that instructs the kernel to use the old InputID range check
logic in iort_id_map(), so that we can support both firmwares written
with the flawed 'Number of IDs' logic and the correct one as defined in
the specifications.
[0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf
Reported-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/
Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Pankaj Bansal <pankaj.bansal@nxp.com>
Cc: Will Deacon <will@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/acpi/arm64/iort.c | 57 +++++++++++++++++++++++++++++++++++++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e11b5da6f828f..7d86468300b78 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -306,6 +306,59 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
return status;
}
+struct iort_workaround_oem_info {
+ char oem_id[ACPI_OEM_ID_SIZE + 1];
+ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+ u32 oem_revision;
+};
+
+static bool apply_id_count_workaround;
+
+static struct iort_workaround_oem_info wa_info[] __initdata = {
+ {
+ .oem_id = "HISI ",
+ .oem_table_id = "HIP07 ",
+ .oem_revision = 0,
+ }, {
+ .oem_id = "HISI ",
+ .oem_table_id = "HIP08 ",
+ .oem_revision = 0,
+ }
+};
+
+static void __init
+iort_check_id_count_workaround(struct acpi_table_header *tbl)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(wa_info); i++) {
+ if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) &&
+ !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id, ACPI_OEM_TABLE_ID_SIZE) &&
+ wa_info[i].oem_revision == tbl->oem_revision) {
+ apply_id_count_workaround = true;
+ pr_warn(FW_BUG "ID count for ID mapping entry is wrong, applying workaround\n");
+ break;
+ }
+ }
+}
+
+static inline u32 iort_get_map_max(struct acpi_iort_id_mapping *map)
+{
+ u32 map_max = map->input_base + map->id_count;
+
+ /*
+ * The IORT specification revision D (Section 3, table 4, page 9) says
+ * Number of IDs = The number of IDs in the range minus one, but the
+ * IORT code ignored the "minus one", and some firmware did that too,
+ * so apply a workaround here to keep compatible with both the spec
+ * compliant and non-spec compliant firmwares.
+ */
+ if (apply_id_count_workaround)
+ map_max--;
+
+ return map_max;
+}
+
static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
u32 *rid_out)
{
@@ -322,8 +375,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
return -ENXIO;
}
- if (rid_in < map->input_base ||
- (rid_in >= map->input_base + map->id_count))
+ if (rid_in < map->input_base || rid_in > iort_get_map_max(map))
return -ENXIO;
*rid_out = map->output_base + (rid_in - map->input_base);
@@ -1542,5 +1594,6 @@ void __init acpi_iort_init(void)
return;
}
+ iort_check_id_count_workaround(iort_table);
iort_init_platform_devices();
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 188/252] x86/mm: Fix NX bit clearing issue in kernel_map_pages_in_pgd
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ard Biesheuvel, Ingo Molnar, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Ard Biesheuvel <ardb@kernel.org>
[ Upstream commit 75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e ]
The following commit:
15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()")
modified kernel_map_pages_in_pgd() to manage writable permissions
of memory mappings in the EFI page table in a different way, but
in the process, it removed the ability to clear NX attributes from
read-only mappings, by clobbering the clear mask if _PAGE_RW is not
being requested.
Failure to remove the NX attribute from read-only mappings is
unlikely to be a security issue, but it does prevent us from
tightening the permissions in the EFI page tables going forward,
so let's fix it now.
Fixes: 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-5-ardb@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/mm/pageattr.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index e2d4b25c7aa44..101f3ad0d6ad1 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -2126,19 +2126,13 @@ int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
.pgd = pgd,
.numpages = numpages,
.mask_set = __pgprot(0),
- .mask_clr = __pgprot(0),
+ .mask_clr = __pgprot(~page_flags & (_PAGE_NX|_PAGE_RW)),
.flags = 0,
};
if (!(__supported_pte_mask & _PAGE_NX))
goto out;
- if (!(page_flags & _PAGE_NX))
- cpa.mask_clr = __pgprot(_PAGE_NX);
-
- if (!(page_flags & _PAGE_RW))
- cpa.mask_clr = __pgprot(_PAGE_RW);
-
if (!(page_flags & _PAGE_ENC))
cpa.mask_clr = pgprot_encrypted(cpa.mask_clr);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 187/252] f2fs: fix memleak of kobject
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Chao Yu, Jaegeuk Kim, Sasha Levin, linux-f2fs-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Chao Yu <yuchao0@huawei.com>
[ Upstream commit fe396ad8e7526f059f7b8c7290d33a1b84adacab ]
If kobject_init_and_add() failed, caller needs to invoke kobject_put()
to release kobject explicitly.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/f2fs/sysfs.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index b405548202d3b..9a59f49ba4050 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -658,10 +658,12 @@ int __init f2fs_init_sysfs(void)
ret = kobject_init_and_add(&f2fs_feat, &f2fs_feat_ktype,
NULL, "features");
- if (ret)
+ if (ret) {
+ kobject_put(&f2fs_feat);
kset_unregister(&f2fs_kset);
- else
+ } else {
f2fs_proc_root = proc_mkdir("fs/f2fs", NULL);
+ }
return ret;
}
@@ -682,8 +684,11 @@ int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
init_completion(&sbi->s_kobj_unregister);
err = kobject_init_and_add(&sbi->s_kobj, &f2fs_sb_ktype, NULL,
"%s", sb->s_id);
- if (err)
+ if (err) {
+ kobject_put(&sbi->s_kobj);
+ wait_for_completion(&sbi->s_kobj_unregister);
return err;
+ }
if (f2fs_proc_root)
sbi->s_proc = proc_mkdir(sb->s_id, f2fs_proc_root);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 190/252] ide: remove set but not used variable 'hwif'
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wang Hai, Hulk Robot, David S . Miller, Sasha Levin, linux-ide,
linuxppc-dev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98949a1946d70771789def0c9dbc239497f9f138 ]
Fix the following gcc warning:
drivers/ide/pmac.c: In function pmac_ide_setup_device:
drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
[-Wunused-but-set-variable]
Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/pmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index 203ed4adc04ae..7db083ec5ee06 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1024,7 +1024,6 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
struct device_node *np = pmif->node;
const int *bidp;
struct ide_host *host;
- ide_hwif_t *hwif;
struct ide_hw *hws[] = { hw };
struct ide_port_info d = pmac_port_info;
int rc;
@@ -1080,7 +1079,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
rc = -ENOMEM;
goto bail;
}
- hwif = pmif->hwif = host->ports[0];
+ pmif->hwif = host->ports[0];
if (on_media_bay(pmif)) {
/* Fixup bus ID for media bay */
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 192/252] ide: serverworks: potential overflow in svwks_set_pio_mode()
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, David S . Miller, Sasha Levin, linux-ide
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit ce1f31b4c0b9551dd51874dd5364654ed4ca13ae ]
The "drive->dn" variable is a u8 controlled by root.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/serverworks.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/ide/serverworks.c b/drivers/ide/serverworks.c
index a97affca18abe..0f57d45484d1d 100644
--- a/drivers/ide/serverworks.c
+++ b/drivers/ide/serverworks.c
@@ -114,6 +114,9 @@ static void svwks_set_pio_mode(ide_hwif_t *hwif, ide_drive_t *drive)
struct pci_dev *dev = to_pci_dev(hwif->dev);
const u8 pio = drive->pio_mode - XFER_PIO_0;
+ if (drive->dn >= ARRAY_SIZE(drive_pci))
+ return;
+
pci_write_config_byte(dev, drive_pci[drive->dn], pio_modes[pio]);
if (svwks_csb_check(dev)) {
@@ -140,6 +143,9 @@ static void svwks_set_dma_mode(ide_hwif_t *hwif, ide_drive_t *drive)
u8 ultra_enable = 0, ultra_timing = 0, dma_timing = 0;
+ if (drive->dn >= ARRAY_SIZE(drive_pci2))
+ return;
+
pci_read_config_byte(dev, (0x56|hwif->channel), &ultra_timing);
pci_read_config_byte(dev, 0x54, &ultra_enable);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 191/252] cmd64x: potential buffer overflow in cmd64x_program_timings()
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, David S . Miller, Sasha Levin, linux-ide
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 117fcc3053606d8db5cef8821dca15022ae578bb ]
The "drive->dn" value is a u8 and it is controlled by root only, but
it could be out of bounds here so let's check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/cmd64x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ide/cmd64x.c b/drivers/ide/cmd64x.c
index b127ed60c7336..9dde8390da09b 100644
--- a/drivers/ide/cmd64x.c
+++ b/drivers/ide/cmd64x.c
@@ -65,6 +65,9 @@ static void cmd64x_program_timings(ide_drive_t *drive, u8 mode)
struct ide_timing t;
u8 arttim = 0;
+ if (drive->dn >= ARRAY_SIZE(drwtim_regs))
+ return;
+
ide_timing_compute(drive, mode, &t, T, 0);
/*
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Tony Lindgren @ 2020-02-14 17:03 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, alsa-devel, linux-kernel, linux-omap, Aaro Koskinen,
Arthur D ., Jarkko Nikula, Merlijn Wajer, Pavel Machek,
Sebastian Reichel
In-Reply-To: <346dfd2b-23f8-87e0-6f45-27a5099b1066@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [200214 12:42]:
> Hi Tony,
>
> On 12/02/2020 16.35, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi@ti.com> [200212 08:02]:
> >>
> >>
> >> On 11/02/2020 19.16, Tony Lindgren wrote:
> >>> We can have multiple connections on a single McBSP instance configured
> >>> with audio graph card when using TDM (Time Division Multiplexing). Let's
> >>> allow that by configuring dais dynamically.
> >>
> >> It is still one DAI...
> >> If you have multiple codec connected to the same I2S lines, but the
> >> codecs communicate within different time slots, you still have one DAI
> >> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
> >
> > OK so subject should say "dodec DAIs" then I guess?
> >
> >>> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> >>> Documentation/devicetree/bindings/graph.txt for more details for
> >>> multiple endpoints.
> >>
> >> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
> >> The PCM3168a have 2 DAIs: playback and capture, but you can have
> >> multiple endpoints within a DAI.
> >
> > Yes this should follow the audio-graph-card.txt example. We end up with
> > mcbsp3 dts node as below on droid4:
> >
> > &mcbsp3 {
> > #sound-dai-cells = <0>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&mcbsp3_pins>;
> > status = "okay";
> >
> > ports {
> > mcbsp3_port: port@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > cpu_dai3: endpoint@0 {
> > reg = <0>;
> > dai-format = "dsp_a";
> > frame-master = <&cpcap_audio_codec1>;
> > bitclock-master = <&cpcap_audio_codec1>;
> > remote-endpoint = <&cpcap_audio_codec1>;
> > };
> >
> > cpu_dai_mdm: endpoint@1 {
> > reg = <1>;
> > dai-format = "dsp_a";
> > frame-master = <&cpcap_audio_codec1>;
> > bitclock-master = <&cpcap_audio_codec1>;
> > remote-endpoint = <&mot_mdm6600_audio_codec0>;
> > };
> > };
> > };
> > };
>
> According to
> Documentation/devicetree/bindings/sound/audio-graph-card.txt
> it should be something like this:
> &mcbsp3 {
> #sound-dai-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&mcbsp3_pins>;
> status = "okay";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
>
> cpu_dai3: endpoint@0 {
> dai-format = "dsp_a";
> frame-master = <&cpcap_audio_codec1>;
> bitclock-master = <&cpcap_audio_codec1>;
> remote-endpoint = <&cpcap_audio_codec1>;
> };
>
> cpu_dai_mdm: endpoint@1 {
> dai-format = "dsp_a";
> frame-master = <&cpcap_audio_codec1>;
> bitclock-master = <&cpcap_audio_codec1>;
> remote-endpoint = <&mot_mdm6600_audio_codec0>;
> };
> };
> };
> };
Hmms so I only spot reg use at different level changing above. Well
that's not according to Documentation/devicetree/bindings/graph.txt,
the reg numbering is per endpoint.
Sounds like the we have the example not following graph.txt in
Documentation/devicetree/bindings/sound/audio-graph-card.txt while
the code is now behaving as in graph.txt.
> If you span out dummy DAIs got dai1+ then how you will get anything
> working via endpoint1+?
> There will be no ops for McBSP, so it is not going to do anything...
Eventually it could have ops though. For things like capture of the tdm
slot data for recording audio call for example, I don't know how that's
supposed to work though. I guess mcbsp could be the clock master too,
and for those cases it would have ops.
But right now in droid4 voice call case mcbsp is just the i2s transport,
and everything happens betwee the modem and the cpcap pmic.
> > That is pretty much the same as the 'Multi DAI with DPCM' example, with
> > dne dai, and multiple endpoints. I think we still have just one port
> > for one i2s transport on the mcbsp :)
> >
> > Does the above look as what you would expect based on the binding?
>
> The audio-graph-card.txt example shows pcm3168a which have two DAIs,
> one for playback and one for capture.
>
> I guess Morimoto-san can explain if he carries out of tree patches to
> get the described setup working on top of mainline...
>
> But, no, based on the documentation I don't ;)
Sounds like audio-graph-card.txt is just out of sync with graph.txt
as we do have several working examples?
> >>> I've tested this with droid4 where cpcap pmic and modem voice are both
> >>> both wired to mcbsp3. I've also tested this on droid4 both with and
> >>> without the pending modem audio codec driver that is waiting for n_gsm
> >>> serdev dependencies to clear.
> >>
> >> What this patch you effectively just creating dummy-dais on top of the
> >> real McBSP DAI.
> >
> > Yes I think this is needed for snd-soc-audio-graph-card, and this allows
> > configuring whatever is needed for the i2s slot. But maybe you have some
> > better way of doing it in mind?
> >
> >> You also rename the DAIs, which might break ams-delta.
> >
> > Oops, that's not good. So should we just keep the old naming if there's
> > only one endpoint?
>
> That's an option, yes, if we really need extra dummy McBSP DAIs at all,
> again, let's hear from Morimoto-san or Mark.
Well it would not necessarily be a dummy mcbsp dai in all cases it seems
to me. But yeah nothing for the second dai to do right now for droid4
voice call as it's all between the modem and the pmic.
> >> We still have legacy support in
> >> omap-twl4030.c
> >> omap3pandora.c
> >> osk5912.c
> >> rx51.c
> >>
> >> which will break with the renamed DAI. On the other hand I think the
> >> legacy support can be dropped from them.
> >
> > I'm not sure what all that would take.
>
> For some it should not be a big deal as they only boot in DT mode.
> /me adds this to the TODO list.
OK
> >> I know it was discussed, but can not find the mail:
> >> Can you brief again on the audio connection?
> >
> > Below is a link to a mailing list thread where Sebastian describes
> > the audio connection:
> >
> > https://lkml.org/lkml/2018/3/28/881
>
> Thanks!
>
> >> Do you have branch with working code?
> >
> > Yeah I have slightly older set of the patches in my droid4-pending-v5.5
> > kernel.org git branch with voice calls working.
>
> I think I should put my droid4 out and try to get it working...
> Do you have a link for dummies to follow to get started? ;)
Probably the easiest one to use right now is the Maemo-leste devuan based
test image using v5.5 kernel + modem and audio patches:
https://leste.maemo.org/Motorola_Droid_4
Just use a decent speed micro-sd card rated "a1" for example.
Regards,
Tony
^ permalink raw reply
* [PATCH AUTOSEL 4.19 194/252] btrfs: fix possible NULL-pointer dereference in integrity checks
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johannes Thumshirn, David Sterba, Sasha Levin, linux-btrfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Johannes Thumshirn <jth@kernel.org>
[ Upstream commit 3dbd351df42109902fbcebf27104149226a4fcd9 ]
A user reports a possible NULL-pointer dereference in
btrfsic_process_superblock(). We are assigning state->fs_info to a local
fs_info variable and afterwards checking for the presence of state.
While we would BUG_ON() a NULL state anyways, we can also just remove
the local fs_info copy, as fs_info is only used once as the first
argument for btrfs_num_copies(). There we can just pass in
state->fs_info as well.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205003
Signed-off-by: Johannes Thumshirn <jth@kernel.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/check-integrity.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 833cf3c35b4df..3b77c8ab5357e 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -629,7 +629,6 @@ static struct btrfsic_dev_state *btrfsic_dev_state_hashtable_lookup(dev_t dev,
static int btrfsic_process_superblock(struct btrfsic_state *state,
struct btrfs_fs_devices *fs_devices)
{
- struct btrfs_fs_info *fs_info = state->fs_info;
struct btrfs_super_block *selected_super;
struct list_head *dev_head = &fs_devices->devices;
struct btrfs_device *device;
@@ -700,7 +699,7 @@ static int btrfsic_process_superblock(struct btrfsic_state *state,
break;
}
- num_copies = btrfs_num_copies(fs_info, next_bytenr,
+ num_copies = btrfs_num_copies(state->fs_info, next_bytenr,
state->metablock_size);
if (state->print_mask & BTRFSIC_PRINT_MASK_NUM_COPIES)
pr_info("num_copies(log_bytenr=%llu) = %d\n",
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/3] PCI: Add DMA configuration for virtual platforms
From: Robin Murphy @ 2020-02-14 17:03 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, virtualization, linux-pci
Cc: kevin.tian, mst, jasowang, sebastien.boeuf, jacob.jun.pan,
bhelgaas
In-Reply-To: <20200214160413.1475396-3-jean-philippe@linaro.org>
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> Hardware platforms usually describe the IOMMU topology using either
> device-tree pointers or vendor-specific ACPI tables. For virtual
> platforms that don't provide a device-tree, the virtio-iommu device
> contains a description of the endpoints it manages. That information
> allows us to probe endpoints after the IOMMU is probed (possibly as late
> as userspace modprobe), provided it is discovered early enough.
>
> Add a hook to pci_dma_configure(), which returns -EPROBE_DEFER if the
> endpoint is managed by a vIOMMU that will be loaded later, or 0 in any
> other case to avoid disturbing the normal DMA configuration methods.
> When CONFIG_VIRTIO_IOMMU_TOPOLOGY isn't selected, the call to
> virt_dma_configure() is compiled out.
>
> As long as the information is consistent, platforms can provide both a
> device-tree and a built-in topology, and the IOMMU infrastructure is
> able to deal with multiple DMA configuration methods.
Urgh, it's already been established[1] that having IOMMU setup tied to
DMA configuration at driver probe time is not just conceptually wrong
but actually broken, so the concept here worries me a bit. In a world
where of_iommu_configure() and friends are being called much earlier
around iommu_probe_device() time, how badly will this fall apart?
Robin.
[1]
https://lore.kernel.org/linux-iommu/9625faf4-48ef-2dd3-d82f-931d9cf26976@huawei.com/
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/pci/pci-driver.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 0454ca0e4e3f..69303a814f21 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -18,6 +18,7 @@
> #include <linux/kexec.h>
> #include <linux/of_device.h>
> #include <linux/acpi.h>
> +#include <linux/virt_iommu.h>
> #include "pci.h"
> #include "pcie/portdrv.h"
>
> @@ -1602,6 +1603,10 @@ static int pci_dma_configure(struct device *dev)
> struct device *bridge;
> int ret = 0;
>
> + ret = virt_dma_configure(dev);
> + if (ret)
> + return ret;
> +
> bridge = pci_get_host_bridge_device(to_pci_dev(dev));
>
> if (IS_ENABLED(CONFIG_OF) && bridge->parent &&
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH AUTOSEL 4.19 195/252] btrfs: safely advance counter when looking up bio csums
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: David Sterba, Dan Carpenter, Josef Bacik, Sasha Levin,
linux-btrfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: David Sterba <dsterba@suse.com>
[ Upstream commit 4babad10198fa73fe73239d02c2e99e3333f5f5c ]
Dan's smatch tool reports
fs/btrfs/file-item.c:295 btrfs_lookup_bio_sums()
warn: should this be 'count == -1'
which points to the while (count--) loop. With count == 0 the check
itself could decrement it to -1. There's a WARN_ON a few lines below
that has never been seen in practice though.
It turns out that the value of page_bytes_left matches the count (by
sectorsize multiples). The loop never reaches the state where count
would go to -1, because page_bytes_left == 0 is found first and this
breaks out.
For clarity, use only plain check on count (and only for positive
value), decrement safely inside the loop. Any other discrepancy after
the whole bio list processing should be reported by the exising
WARN_ON_ONCE as well.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/file-item.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index 4cf2817ab1202..f9e280d0b44f3 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -275,7 +275,8 @@ static blk_status_t __btrfs_lookup_bio_sums(struct inode *inode, struct bio *bio
csum += count * csum_size;
nblocks -= count;
next:
- while (count--) {
+ while (count > 0) {
+ count--;
disk_bytenr += fs_info->sectorsize;
offset += fs_info->sectorsize;
page_bytes_left -= fs_info->sectorsize;
--
2.20.1
^ 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.