* Re: Xen Project Security Whitepaper v1 is ready for community review
From: Steven Haigh @ 2018-05-18 15:55 UTC (permalink / raw)
To: xen-devel; +Cc: Lars Kurth
In-Reply-To: <6011F946-60DB-4EF0-B335-5333D3F56F74@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 4634 bytes --]
Hi Lars,
I think this is an excellent start.
A specific concern that I have is when we get into a state between releases
and XSAs where you cannot take the current release and then apply all released
/ embargo'ed XSA patches.
The current reasoning for this is that XSA patches are developed on top of the
staging git branches. While this is still acceptable, I believe we need the
ability to roll a new point release that will allow end users to be up to
date.
Expecting things to always be built for distribution from the staging git
branch is somewhat of a hassle - as in the current case of 4.9.1. With
publicly released XSAs, you cannot begin with a release of 4.9.1 and patch all
post-released XSAs.
While this does not seem to happen very often - I would estimate around 4-5
times in the past decade - we should encourage an out-of-schedule point
release. This can be based off the current state post-XSA of the staging
branch - but enables reproducable builds at the very least.
Recently, this situation happened with the batch of XSAs before 4.10.1 was
released, and is currently the case of 4.9.1 + existing XSAs.
This potentially leaves end users in limbo until the next point release rolls
around - without rebasing off a semi-random git commit (which is not 4.9.1 or
4.9.2 - but something inbetween) - or backporting massive amounts of commits
to a release.
As this is a somewhat rare occasion, if only a handful of commits need to be
cherrypicked, I would see this as fine. If it requires many more, I believe it
should trigger an out-of-cycle point release.
--
Steven Haigh
📧 netwiz@crc.id.au 💻 https://www.crc.id.au
📞 +61 (3) 9001 6090 📱 0412 935 897
On Friday, 18 May 2018 8:13:55 PM AEST Lars Kurth wrote:
> Dear Community Members,
>
> just under 3 months ago, we started a community consultation titled "Xen
> Security Process Consultation: is there a case to change anything?" (see
> https://lists.xenproject.org/archives/html/xen-announce/2018-02/msg00000.ht
> ml). As promised, I would collate the input - together with further analysis
> trying to genuinely consider the implications of what respondents to the
> consultation have been suggesting - in a white paper. The white paper is
> attached and contains
> 1) Baseline: an analysis of our XSAs and how we dealt with XSAs in the
> recent past
2) Results from the Community Consultation
> 2.1) Feedback received from a community consultation
> 2.2) Analysis
> 3) Recommendations and policy changes - some is quite extensive to try and
> tries to evaluate the impact of policy changes, which would result if we
> implemented solutions to issues highlighted by our users.
> The next step is for community members to provide public feedback. If it
> turns out there is a case for changes/improvements, I will condense the
> output of this discussion into a concrete change proposal (or a series
> thereof) to be voted on in the usual way. This may require several
> iterations. Note that the document contains workflow and tools related
> feedback, which I did not anticipate. Some issues highlighted should be
> easy to fix, others will require additional discussion on xen-devel@, such
> as
* Inconsistent Meta Data and XSA prerequisites
> * Git baseline of patches
> * Release cycle related (issues)
>
> The document tries to label all discussion items, such that it is easy to
> comment. I normally attach a converted markdown version: however, this is
> unwieldly in this case, because there is a large number of tables and
> images. Thus, I have created a google doc copy which allows anyone with the
> following link
> https://docs.google.com/document/d/1FbGV4ZZB9OU8SI4b9ntnM-l6NaQLND8Yfd9u11V
> 5Q5A/edit?usp=sharing to comment on sections of the document. If you do,
> please make sure you identify yourself in the comment and/or also highlight
> feedback in the e-mail thread discussion that will follow this document.
>
> Please also let us know areas of the whitepaper you agree with, as this will
> make it overall easier to identify how much consensus there would be to
> address specific issues and proposals in the document. Otherwise the
> discussion will primarily focus on points of contention, while other areas
> where in fact there may be consensus, will be missed. If there is little or
> no feedback (either positive or negative), we have to assume that people
> are happy with the status quo and that there is only a weak case for
> changes.
> Best Regards
> Lars
>
>
>
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2] app/testpmd: fix pmd_test_exit function for vdevs
From: Matan Azrad @ 2018-05-18 15:55 UTC (permalink / raw)
To: Ferruh Yigit, Iremonger, Bernard, Yao, Lei A, Yang, Zhiyong,
dev@dpdk.org
Cc: maxime.coquelin@redhat.com, Bie, Tiwei, stable@dpdk.org,
Thomas Monjalon
In-Reply-To: <5a7b433f-e145-7fb2-f673-ca2861da8ee6@intel.com>
Hi all
While this patch also applied I don't understand it.
Is it mandatory for each PMD to free all its resources in dev_close()?
Or it should be done by the rte_device remove function?
If the resource cleanup should be done by the remove function I think it
should be called for all the devices (pci, vdev, etc).
Is there an exit function for EAL to clean rte_eal_init()? If no, looks like we need it...
From: Ferruh Yigit
>
> On 5/18/2018 11:18 AM, Iremonger, Bernard wrote:
> > Hi Ferruh, Zhiyong,
> >
> > <snip>
> >
> >>> Subject: [PATCH v2] app/testpmd: fix pmd_test_exit function for
> >>> vdevs
> >>>
> >>> For vdev, just calling rte_eth_dev_close() isn't enough to free all
> >>> the resources allocated during device probe, e.g. for virtio-user,
> >>> virtio_user_pmd_remove(), i.e. the remove() method of a vdev driver,
> >>> needs to be called to unlink the socket file created during device
> >>> probe. So this patch calls the rte_eth_dev_detach() for vdev when
> >>> quitting testpmd.
> >>>
> >>> Cc: maxime.coquelin@redhat.com
> >>> Cc: ferruh.yigit@intel.com
> >>> Cc: tiwei.bie@intel.com
> >>> Cc: lei.a.yao@intel.com
> >>> Cc: bernard.iremonger@intel.com
> >>> Cc: stable@dpdk.org
> >>>
> >>> Fixes: af75078fece3 ("first public release")
> >>> Fixes: bd8f50a45d0f ("net/virtio-user: support server mode")
> >>>
> >>> Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
> >> Tested-by: Lei Yao<lei.a.yao@intel.com> This patch pass the test for
> >> virtio-user server mode. The socket file can be deleted after quit
> >> testpmd.
> >
> > Acked-by: Bernard Iremonger <bernard.iremonger@intel.com>
>
> Applied to dpdk-next-net/master, thanks.
>
>
> > Check-git-log is showing some errors:
> >
> > ./devtools/check-git-log.sh -1
> > Wrong headline format:
> > app/testpmd: fix pmd_test_exit function for vdevs Wrong tag:
> > Tested-by: Lei Yao<lei.a.yao@intel.com>
>
> fixed while applying.
^ permalink raw reply
* Re: [PATCH 19/19] ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks
From: Hans de Goede @ 2018-05-18 15:55 UTC (permalink / raw)
To: Pierre-Louis Bossart, Liam Girdwood, Mark Brown, Bard Liao,
Oder Chiou
Cc: alsa-devel, Takashi Iwai
In-Reply-To: <1fd841b6-1e05-2cd9-8b0e-44524503a3fa@redhat.com>
Hi Pierre-Louis,
On 10-05-18 17:48, Hans de Goede wrote:
> Hi,
>
> On 10-05-18 17:00, Pierre-Louis Bossart wrote:
>> On 5/10/18 5:27 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 08-05-18 20:35, Pierre-Louis Bossart wrote:
>>>> On 5/8/18 10:36 AM, Hans de Goede wrote:
>>>>> Many X86 devices using a BYT SoC + RT5640 codec are cheap devices with
>>>>> generic DMI strings, causing snd_soc_set_dmi_name() to fail to set a
>>>>> long_name, making it impossible for userspace to have a correct UCM
>>>>> profile which only uses inputs / outputs which are actually hooked up
>>>>> on the device.
>>>>>
>>>>> Our quirks already specify which input the internal mic is connected to
>>>>> and if a single (mono) speaker is used or if the device has stereo
>>>>> speakers.
>>>>>
>>>>> This commit sets a long_name based on the quirks so that userspace can
>>>>> have UCM profiles doing the right thing based on the long_name.
>>>>
>>>> Isn't this going to be complicated to manage for UCM? Just with this patch alone, you'd need 8 UCM files to cover all the combinations. 16 if you add the 'sof-' prefix.
>>>>
>>>> seems like UCM should become more 'dynamic' and get quirk information somehow (sysfs?) to enable/disable endpoints rather than rely on name encoding to select the right profile?
>>>
>>> I agree that this is not ideal, but this is an improvement from the
>>> current state where we would need 1 UCM profile per board
>>> (assuming valid DMI data and thus a proper long-name being set),
>>> 6 profiles (dmic2 is not used anywhere sofar) is a whole lot easier
>>> to manage then 1 profile per board. So as said I believe this is
>>> a step in the right direction.
>>>
>>> And looking at the foreseeable future I simply don't see any of us
>>> having the time to implement an ideal solution for this. I would
>>> really like for end users to be able to run the latest upstream
>>> kernel + alsa-lib and have things just work, before this hardware
>>> becomes obsolete. I know that no-one having time to work on reworking
>>> UCM to make it more dynamic is not the best of arguments but it
>>> is something to take into consideration.
>>>
>>> Thinking more about this on the alsa-lib / UCM profile side we
>>> could have something like this:
>>>
>>> /usr/share/alsa/ucm/bytcr-rt5640-mono-spk-in1-mic/bytcr-rt5640-mono-spk-in1-mic.conf:
>>>
>>> SectionUseCase."HiFi" {
>>> File "../bytcr-rt5640/Generic.conf"
>>> File "../bytcr-rt5640/MonoSpeaker.conf"
>>> File "../bytcr-rt5640/In1Mic.conf"
>>> Comment "Play HiFi quality Music"
>>> }
>>>
>>> SectionDefaults [
>>> cdev "hw:bytcrrt5640"
>>> ]
>>>
>>> The only problem I can see with that is that the "ConflictingDevice"
>>> sections for the various inputs / outputs then would refer to not
>>> present SectionDevice sections. I have not tested this suggestion yet,
>>> but I'm willing to write an alsa-lib patch to ignore non present
>>> ConflictingDevice references, to make my suggestion work.
>>>
>>> I think doing things this way, thus avoiding the need to copy and
>>> paste a whole lot of UCM code for the 6 profiles it will not be
>>> a problem to maintain 6 profiles, as we're really just maintaining
>>> 6 config snippets such as the above example and only one complete
>>> profile.
>>>
>>> Would the solution I outlined above be acceptable to you?
>>
>> The includes and disabling conflicting devices that aren't present make sense. I have another issue though: for SOF integration I already prepared a set of files, which are mostly identical to the regular ones except that the platform-side mixer controls are removed (or different) and the name of the card/device is different (sof- prefix). See on github.
>
> Hmm, it might make sense to split the includes in platform and codec includes, so
> to pick my example again we would get:
>
> /usr/share/alsa/ucm/bytcr-rt5640-mono-spk-in1-mic/bytcr-rt5640-mono-spk-in1-mic.conf:
>
> SectionUseCase."HiFi" {
> SectionVerb {
> EnableSequence [
> cdev "hw:bytcrrt5640"
>
> File "../bytcr-rt5640/EnableSeq.conf" # This contains the platform mixer settings
> File "../rt5640/EnableSeq.conf"
> ]
>
> DisableSequence [
> ]
>
> Value {
> PlaybackPCM "hw:bytcrrt5640"
> CapturePCM "hw:bytcrrt5640"
> }
> }
>
> File "../rt5640/Headset.conf"
> File "../rt5640/MonoSpeaker.conf"
> File "../rt5640/In1Mic.conf"
> Comment "Play HiFi quality Music"
> }
>
> SectionDefaults [
> cdev "hw:bytcrrt5640"
> ]
>
> And then for sof you would just need to
> offer a sof-rt5640/EnableSeq.conf, or
> maybe even leave it out completely.
>
> And we might also be able to merge the platform
> enable sequences into a generic:
>
> bytcr/EnableSeq.conf
>
> I think that will at least fly for bytcr-rt5640 and
> butcr-rt5651, leading us being able to remove more
> duplicated UCM config. >
> How does this sound?
I've implemented the above scheme, see:
https://github.com/jwrdegoede/alsa-lib/commits/master
This seems to work well (I still need to test a
bit more, but so far the generic and one long-name
based profile work fine) and Mark has merged the
"ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks"
patch in his for-next branch, so I plan to submit
the matching alsa-lib patches from my github for
upstream alsa-lib inclusion soon.
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [PATCH v2 net-next] net: stmmac: Populate missing callbacks in HWIF initialization
From: Jose Abreu @ 2018-05-18 15:54 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Corentin Labbe, David S. Miller, Joao Pinto,
Giuseppe Cavallaro, Alexandre Torgue
Some HW specific setups, like sun8i, do not populate all the necessary
callbacks, which is what HWIF helpers were expecting.
Fix this by always trying to get the generic helpers and populate them
if they were not previously populated by HW specific setup.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Fixes: 5f0456b43140 ("net: stmmac: Implement logic to automatically
select HW Interface")
Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
Changes from v1:
- Rebased to latest net-next
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 38 ++++++++++++++++-----------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 23a1264..14770fc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -189,13 +189,16 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
bool needs_gmac = priv->plat->has_gmac;
const struct stmmac_hwif_entry *entry;
struct mac_device_info *mac;
+ bool needs_setup = true;
int i, ret;
u32 id;
if (needs_gmac) {
id = stmmac_get_id(priv, GMAC_VERSION);
- } else {
+ } else if (needs_gmac4) {
id = stmmac_get_id(priv, GMAC4_VERSION);
+ } else {
+ id = 0;
}
/* Save ID for later use */
@@ -209,13 +212,12 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Check for HW specific setup first */
if (priv->plat->setup) {
- priv->hw = priv->plat->setup(priv);
- if (!priv->hw)
- return -ENOMEM;
- return 0;
+ mac = priv->plat->setup(priv);
+ needs_setup = false;
+ } else {
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
}
- mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
if (!mac)
return -ENOMEM;
@@ -227,24 +229,28 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
continue;
if (needs_gmac4 ^ entry->gmac4)
continue;
- if (id < entry->min_id)
+ /* Use synopsys_id var because some setups can override this */
+ if (priv->synopsys_id < entry->min_id)
continue;
- mac->desc = entry->desc;
- mac->dma = entry->dma;
- mac->mac = entry->mac;
- mac->ptp = entry->hwtimestamp;
- mac->mode = entry->mode;
- mac->tc = entry->tc;
+ /* Only use generic HW helpers if needed */
+ mac->desc = mac->desc ? : entry->desc;
+ mac->dma = mac->dma ? : entry->dma;
+ mac->mac = mac->mac ? : entry->mac;
+ mac->ptp = mac->ptp ? : entry->hwtimestamp;
+ mac->mode = mac->mode ? : entry->mode;
+ mac->tc = mac->tc ? : entry->tc;
priv->hw = mac;
priv->ptpaddr = priv->ioaddr + entry->regs.ptp_off;
priv->mmcaddr = priv->ioaddr + entry->regs.mmc_off;
/* Entry found */
- ret = entry->setup(priv);
- if (ret)
- return ret;
+ if (needs_setup) {
+ ret = entry->setup(priv);
+ if (ret)
+ return ret;
+ }
/* Run quirks, if needed */
if (entry->quirks) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/6] x86: bug: prevent gcc distortions
From: Borislav Petkov @ 2018-05-18 15:53 UTC (permalink / raw)
To: Nadav Amit
Cc: Ingo Molnar, Peter Zijlstra, linux-kernel@vger.kernel.org,
x86@kernel.org, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Josh Poimboeuf, Linus Torvalds, Andy Lutomirski, Peter Zijlstra,
Denys Vlasenko
In-Reply-To: <30EDFE9B-CA25-42EE-A57F-E3054B84223E@vmware.com>
On Fri, May 18, 2018 at 03:46:33PM +0000, Nadav Amit wrote:
> In case you didn’t read the cover-letter: the patch-set does give a 2%
> performance improvement for #PF-MADV_DONTNEED microbenchmark loop.
I saw it but *micro*-benchmark doesn't tell me a whole lot. If that
"improvement" is not visible in real workloads/benchmarks, then I'm just
as unimpressed.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: Test for osstest, features used in Qubes OS
From: Jan Beulich @ 2018-05-18 15:54 UTC (permalink / raw)
To: Marek Marczykowski; +Cc: Ian Jackson, xen-devel
In-Reply-To: <20180518153344.GC11683@mail-itl>
>>> On 18.05.18 at 17:33, <marmarek@invisiblethingslab.com> wrote:
> Yes, I'm happy to help with that. As I've said, the basic test is very
> simple (rtcwake command) and already very useful. The fact that it is(?)
> broken on staging doesn't make it easier,
Details on the breakage would be appreciated (on a separate thread),
unless you plan to address it yourself. I recall Simon(?) mentioning this as
well, but also not providing sufficient data to consider looking into it
(perhaps simply because it wasn't easy to obtain useful data, as
frequently is the case with S3 resume). I think it would be nice if we could
release 4.11 without a regression here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH] kernfs: fix dentry unexpected skip
From: Hatayama, Daisuke @ 2018-05-18 15:42 UTC (permalink / raw)
To: 'gregkh@linuxfoundation.org'
Cc: Okajima, Toshiyuki, linux-kernel@vger.kernel.org,
'ebiederm@aristanetworks.com'
kernfs_dir_next_pos() overlooks the situation that the dentry
corresponding to a given pos object has already been inactive. Hence,
when kernfs_dir_pos() returns the dentry with a hash value larger than
the original one, kernfs_dir_next_pos() returns the dentry next to the
one returned by kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Suggested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Cc: Eric W. Biederman <ebiederm@aristanetworks.com>
---
fs/kernfs/dir.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 89d1dc1..8a2f49c 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1622,7 +1622,7 @@ static int kernfs_dir_fop_release(struct inode *inode, struct file *filp)
struct kernfs_node *parent, ino_t ino, struct kernfs_node *pos)
{
pos = kernfs_dir_pos(ns, parent, ino, pos);
- if (pos) {
+ if (pos && pos->hash <= ino) {
do {
struct rb_node *node = rb_next(&pos->rb);
if (!node)
--
1.7.1
^ permalink raw reply related
* Re: dm-writecache
From: Dan Williams @ 2018-05-18 15:54 UTC (permalink / raw)
To: Mike Snitzer
Cc: Christoph Hellwig, device-mapper development, Mikulas Patocka,
Alasdair G. Kergon, linux-nvdimm
In-Reply-To: <20180518154454.GA4902@redhat.com>
On Fri, May 18, 2018 at 8:44 AM, Mike Snitzer <snitzer@redhat.com> wrote:
> On Thu, Mar 08 2018 at 12:08pm -0500,
> Dan Williams <dan.j.williams@intel.com> wrote:
>
>> Mikulas sent this useful enhancement to the memcpy_flushcache API:
>>
>> https://patchwork.kernel.org/patch/10217655/
>>
>> ...it's in my queue to either push through -tip or add it to the next
>> libnvdimm pull request for 4.17-rc1.
>
> Hi Dan,
>
> Seems this never actually went upstream. I've staged it in
> linux-dm.git's "for-next" for the time being:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.18&id=a7e96990b5ff6206fefdc5bfe74396bb880f7e48
>
> But do you intend to pick it up for 4.18 inclusion? If so I'll drop
> it.. would just hate for it to get dropped on the floor by getting lost
> in the shuffle between trees.
>
> Please avise, thanks!
> Mike
Thanks for picking it up! I was hoping to resend it to get acks from
x86 folks, and then yes it fell through the cracks in my patch
tracking.
Now that I look at it again I don't think we need this hunk:
void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
size_t len)
{
char *from = kmap_atomic(page);
- memcpy_flushcache(to, from + offset, len);
+ __memcpy_flushcache(to, from + offset, len);
kunmap_atomic(from);
}
...and I wonder what the benefit is of the 16-byte case? I would
assume the bulk of the benefit is limited to the 4 and 8 byte copy
cases.
Mikulas please resend with those comments addressed and include Ingo and Thomas.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: dm-writecache
From: Dan Williams @ 2018-05-18 15:54 UTC (permalink / raw)
To: Mike Snitzer
Cc: Christoph Hellwig, device-mapper development, Mikulas Patocka,
Alasdair G. Kergon, linux-nvdimm
In-Reply-To: <20180518154454.GA4902-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, May 18, 2018 at 8:44 AM, Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Mar 08 2018 at 12:08pm -0500,
> Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
>> Mikulas sent this useful enhancement to the memcpy_flushcache API:
>>
>> https://patchwork.kernel.org/patch/10217655/
>>
>> ...it's in my queue to either push through -tip or add it to the next
>> libnvdimm pull request for 4.17-rc1.
>
> Hi Dan,
>
> Seems this never actually went upstream. I've staged it in
> linux-dm.git's "for-next" for the time being:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.18&id=a7e96990b5ff6206fefdc5bfe74396bb880f7e48
>
> But do you intend to pick it up for 4.18 inclusion? If so I'll drop
> it.. would just hate for it to get dropped on the floor by getting lost
> in the shuffle between trees.
>
> Please avise, thanks!
> Mike
Thanks for picking it up! I was hoping to resend it to get acks from
x86 folks, and then yes it fell through the cracks in my patch
tracking.
Now that I look at it again I don't think we need this hunk:
void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
size_t len)
{
char *from = kmap_atomic(page);
- memcpy_flushcache(to, from + offset, len);
+ __memcpy_flushcache(to, from + offset, len);
kunmap_atomic(from);
}
...and I wonder what the benefit is of the 16-byte case? I would
assume the bulk of the benefit is limited to the 4 and 8 byte copy
cases.
Mikulas please resend with those comments addressed and include Ingo and Thomas.
^ permalink raw reply
* Re: [PATCH 01/10] mm: pagecache add lock
From: Christoph Hellwig @ 2018-05-18 15:53 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kent Overstreet, linux-kernel, linux-fsdevel, Andrew Morton,
Dave Chinner, darrick.wong, tytso, linux-btrfs, clm, jbacik, viro,
peterz
In-Reply-To: <20180518131305.GA6361@bombadil.infradead.org>
On Fri, May 18, 2018 at 06:13:06AM -0700, Matthew Wilcox wrote:
> > Historically, the only problematic case has been direct IO, and people
> > have been willing to say "well, if you mix buffered and direct IO you
> > get what you deserve", and that's probably not unreasonable. But now we
> > have fallocate insert range and collapse range, and those are broken in
> > ways I frankly don't want to think about if they can't ensure consistency
> > with the page cache.
>
> ext4 manages collapse-vs-pagefault with the ext4-specific i_mmap_sem.
> You may get pushback on the grounds that this ought to be a
> filesystem-specific lock rather than one embedded in the generic inode.
Honestly I think this probably should be in the core. But IFF we move
it to the core the existing users of per-fs locks need to be moved
over first. E.g. XFS as the very first one, and at least ext4 and f2fs
that copied the approach, and probably more if you audit deep enough.
^ permalink raw reply
* Re: [PATCH] audit: add containerid support for IMA-audit
From: Richard Guy Briggs @ 2018-05-18 15:51 UTC (permalink / raw)
To: Mimi Zohar
Cc: Stefan Berger, containers, Linux-Audit Mailing List,
linux-integrity, LKML, paul, sgrubb
In-Reply-To: <1526647996.3632.164.camel@linux.vnet.ibm.com>
On 2018-05-18 08:53, Mimi Zohar wrote:
> On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote:
> > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote:
>
> [...]
>
> > >>> auxiliary record either by being converted to a syscall auxiliary record
> > >>> by using current->audit_context rather than NULL when calling
> > >>> audit_log_start(), or creating a local audit_context and calling
> > >> ima_parse_rule() is invoked when setting a policy by writing it into
> > >> /sys/kernel/security/ima/policy. We unfortunately don't have the
> > >> current->audit_context in this case.
> > > Sure you do. What process writes to that file? That's the one we care
> > > about, unless it is somehow handed off to a queue and processed later in
> > > a different context.
> >
> > I just printk'd it again. current->audit_context is NULL in this case.
>
> The builtin policy rules are loaded at __init. Subsequently a custom
> policy can replace the builtin policy rules by writing to the
> securityfs file. Is the audit_context NULL in both cases?
I wondered the same.
> > >> If so, which ones? We could probably refactor the current
> > >> integrity_audit_message() and have ima_parse_rule() call into it to get
> > >> those fields as well. I suppose adding new fields to it wouldn't be
> > >> considered breaking user space?
> > > Changing the order of existing fields or inserting fields could break
> > > stuff and is strongly discouraged without a good reason, but appending
> > > fields is usually the right way to add information.
> > >
> > > There are exceptions, and in this case, I'd pick the "more standard" of
> > > the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and stick
> > > with that, abandoning the other format, renaming the less standard
> > > version of the record (ima_parse_rule?) and perhpas adopting that
> > > abandonned format for the new record type while using
> > > current->audit_context.
>
> This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> ima_audit_measurement(). Could we rename type=1805 to be
> INTEGRITY_AUDIT or INTEGRITY_IMA_AUDIT? The new type=1806 audit
> message could be named INTEGRITY_RULE or, if that would be confusing,
> INTEGRITY_POLICY_RULE.
I'm reluctant to change the macro/value. Just use the existing
AUDIT_INTEGRITY_RULE 1805 as appropriate and create a new
AUDIT_INTEGRITY_AUDIT 1806.
> > 1806 would be in sync with INTEGRITY_RULE now for process related info.
> > If this looks good, I'll remove the dependency on your local context
> > creation and post the series.
> >
> > The justification for the change is that the INTEGRITY_RULE, as produced
> > by ima_parse_rule(), is broken.
>
> Post which series? The IMA namespacing patch set? This change should
> be upstreamed independently of IMA namespacing.
>
> Mimi
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall
From: Daniel Borkmann @ 2018-05-18 15:51 UTC (permalink / raw)
To: Sandipan Das, ast; +Cc: netdev, linuxppc-dev, naveen.n.rao, mpe, jakub.kicinski
In-Reply-To: <20180518125039.6500-7-sandipan@linux.vnet.ibm.com>
On 05/18/2018 02:50 PM, Sandipan Das wrote:
> Currently, for multi-function programs, we cannot get the JITed
> instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD
> command. Because of this, userspace tools such as bpftool fail
> to identify a multi-function program as being JITed or not.
>
> With the JIT enabled and the test program running, this can be
> verified as follows:
>
> # cat /proc/sys/net/core/bpf_jit_enable
> 1
>
> Before applying this patch:
>
> # bpftool prog list
> 1: kprobe name foo tag b811aab41a39ad3d gpl
> loaded_at 2018-05-16T11:43:38+0530 uid 0
> xlated 216B not jited memlock 65536B
> ...
>
> # bpftool prog dump jited id 1
> no instructions returned
>
> After applying this patch:
>
> # bpftool prog list
> 1: kprobe name foo tag b811aab41a39ad3d gpl
> loaded_at 2018-05-16T12:13:01+0530 uid 0
> xlated 216B jited 308B memlock 65536B
> ...
That's really nice! One comment inline below:
> # bpftool prog dump jited id 1
> 0: nop
> 4: nop
> 8: mflr r0
> c: std r0,16(r1)
> 10: stdu r1,-112(r1)
> 14: std r31,104(r1)
> 18: addi r31,r1,48
> 1c: li r3,10
> ...
>
> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> ---
> kernel/bpf/syscall.c | 38 ++++++++++++++++++++++++++++++++------
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 54a72fafe57c..2430d159078c 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1896,7 +1896,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> struct bpf_prog_info info = {};
> u32 info_len = attr->info.info_len;
> char __user *uinsns;
> - u32 ulen;
> + u32 ulen, i;
> int err;
>
> err = check_uarg_tail_zero(uinfo, sizeof(info), info_len);
> @@ -1922,7 +1922,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> ulen = min_t(u32, info.nr_map_ids, ulen);
> if (ulen) {
> u32 __user *user_map_ids = u64_to_user_ptr(info.map_ids);
> - u32 i;
>
> for (i = 0; i < ulen; i++)
> if (put_user(prog->aux->used_maps[i]->id,
> @@ -1970,13 +1969,41 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> * for offload.
> */
> ulen = info.jited_prog_len;
> - info.jited_prog_len = prog->jited_len;
> + if (prog->aux->func_cnt) {
> + info.jited_prog_len = 0;
> + for (i = 0; i < prog->aux->func_cnt; i++)
> + info.jited_prog_len += prog->aux->func[i]->jited_len;
> + } else {
> + info.jited_prog_len = prog->jited_len;
> + }
> +
> if (info.jited_prog_len && ulen) {
> if (bpf_dump_raw_ok()) {
> uinsns = u64_to_user_ptr(info.jited_prog_insns);
> ulen = min_t(u32, info.jited_prog_len, ulen);
> - if (copy_to_user(uinsns, prog->bpf_func, ulen))
> - return -EFAULT;
> +
> + /* for multi-function programs, copy the JITed
> + * instructions for all the functions
> + */
> + if (prog->aux->func_cnt) {
> + u32 len, free;
> + u8 *img;
> +
> + free = ulen;
> + for (i = 0; i < prog->aux->func_cnt; i++) {
> + len = prog->aux->func[i]->jited_len;
> + img = (u8 *) prog->aux->func[i]->bpf_func;
> + if (len > free)
> + break;
> + if (copy_to_user(uinsns, img, len))
> + return -EFAULT;
> + uinsns += len;
> + free -= len;
Is there any way we can introduce a delimiter between the different
images such that they could be more easily correlated with the call
from the main (or other sub-)program instead of having one contiguous
dump blob?
> + }
> + } else {
> + if (copy_to_user(uinsns, prog->bpf_func, ulen))
> + return -EFAULT;
> + }
> } else {
> info.jited_prog_insns = 0;
> }
> @@ -1987,7 +2014,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> if (info.nr_jited_ksyms && ulen) {
> u64 __user *user_jited_ksyms = u64_to_user_ptr(info.jited_ksyms);
> ulong ksym_addr;
> - u32 i;
>
> /* copy the address of the kernel symbol corresponding to
> * each function
>
^ permalink raw reply
* ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: Use intel_fb_obj() everywhere
From: Patchwork @ 2018-05-18 15:51 UTC (permalink / raw)
To: Daniel Stone; +Cc: intel-gfx
In-Reply-To: <20180518143008.4120-1-daniels@collabora.com>
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Use intel_fb_obj() everywhere
URL : https://patchwork.freedesktop.org/series/43421/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4209 -> Patchwork_9053 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/43421/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9053 that come from known issues:
=== IGT changes ===
==== Possible fixes ====
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
fi-hsw-4200u: FAIL (fdo#103481) -> PASS
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
== Participating hosts (43 -> 39) ==
Missing (4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq
== Build changes ==
* Linux: CI_DRM_4209 -> Patchwork_9053
CI_DRM_4209: eecb2c1e793ed98c39876c92fc64cd18a7fe6412 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9053: ea66e36be55d7ec89468751c16abe981725f9187 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit
== Linux commits ==
ea66e36be55d drm/i915: Move GEM BO inside drm_framebuffer
0fde58b9b092 drm/i915: Use intel_fb_obj() everywhere
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9053/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] gpu: ipu-v3: Fix BT1120 interlaced CCIR codes
From: Philipp Zabel @ 2018-05-18 15:51 UTC (permalink / raw)
To: Marek Vasut, linux-media; +Cc: Steve Longerbeam
In-Reply-To: <20180407130428.24833-1-marex@denx.de>
Hi Marek,
On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote:
> The BT1120 interlaced CCIR codes are the same as BT656 ones
> and different than BT656 progressive CCIR codes, fix this.
thank you for the patch, and sorry for the delay.
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/gpu/ipu-v3/ipu-csi.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
> index caa05b0702e1..301a729581ce 100644
> --- a/drivers/gpu/ipu-v3/ipu-csi.c
> +++ b/drivers/gpu/ipu-v3/ipu-csi.c
> @@ -435,12 +435,16 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
> break;
> case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_DDR:
> case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_SDR:
> - case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
> - case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
> ipu_csi_write(csi, 0x40030 | CSI_CCIR_ERR_DET_EN,
> CSI_CCIR_CODE_1);
> ipu_csi_write(csi, 0xFF0000, CSI_CCIR_CODE_3);
> break;
> + case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
> + case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
> + ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN, CSI_CCIR_CODE_1);
> + ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
> + ipu_csi_write(csi, 0xFF0000, CSI_CCIR_CODE_3);
If these are the same as BT656 codes (so this case would be for PAL?),
could this just be moved up into the IPU_CSI_CLK_MODE_CCIR656_INTERLACED
case? Would the NTSC CCIR codes be the same as well?
regards
Philipp
^ permalink raw reply
* Re: [PATCH v4 11/11] iomap: Complete partial direct I/O writes synchronously
From: Christoph Hellwig @ 2018-05-18 15:56 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Christoph Hellwig, cluster-devel, linux-fsdevel, Dave Chinner
In-Reply-To: <CAHc6FU7Td_tabaXM3aSQA8krfxMrgV=NiCcXggf6_aC1WA0nNw@mail.gmail.com>
On Wed, May 16, 2018 at 10:27:18PM +0200, Andreas Gruenbacher wrote:
> I/O completion triggers when dio->ref reaches zero, so
> iomap_dio_bio_end_io will never evaluate submit.waiter before the
> atomic_dec_and_test in iomap_dio_rw. We probably need an
> smp_mb__before_atomic() before that atomic_dec_and_test to make sure
> that iomap_dio_bio_end_io sees the right value of submit.waiter
> though. Any concerns beyond that?
I suspect in the end union usage might still be fine, but it still
looks rather dangerous to scramble over the union that late. It will
also do things like overriding the last_queue pointer which we need
initialized early for block polling.
I suspect something like the variant below will work much better.
This moves the wait_for_completion flag into struct iomap_dio
(in an existing packing hole) and uses that in the completion
handler. It also always initializes the submit fields to prepare
for this early, and makes all fallbacks synchronous (if we ever
get a read fallback that would be the right thing to do).
diff --git a/fs/iomap.c b/fs/iomap.c
index e4617ae1f8d6..54b28a58b7e3 100644
--- a/fs/iomap.c
+++ b/fs/iomap.c
@@ -1327,6 +1327,7 @@ struct iomap_dio {
atomic_t ref;
unsigned flags;
int error;
+ bool wait_for_completion;
union {
/* used during submission and for synchronous completion: */
@@ -1430,7 +1431,7 @@ static void iomap_dio_bio_end_io(struct bio *bio)
iomap_dio_set_error(dio, blk_status_to_errno(bio->bi_status));
if (atomic_dec_and_test(&dio->ref)) {
- if (is_sync_kiocb(dio->iocb)) {
+ if (dio->wait_for_completion) {
struct task_struct *waiter = dio->submit.waiter;
WRITE_ONCE(dio->submit.waiter, NULL);
@@ -1646,13 +1647,12 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
dio->end_io = end_io;
dio->error = 0;
dio->flags = 0;
+ dio->wait_for_completion = is_sync_kiocb(iocb);
dio->submit.iter = iter;
- if (is_sync_kiocb(iocb)) {
- dio->submit.waiter = current;
- dio->submit.cookie = BLK_QC_T_NONE;
- dio->submit.last_queue = NULL;
- }
+ dio->submit.waiter = current;
+ dio->submit.cookie = BLK_QC_T_NONE;
+ dio->submit.last_queue = NULL;
if (iov_iter_rw(iter) == READ) {
if (pos >= dio->i_size)
@@ -1702,7 +1702,7 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
dio_warn_stale_pagecache(iocb->ki_filp);
ret = 0;
- if (iov_iter_rw(iter) == WRITE && !is_sync_kiocb(iocb) &&
+ if (iov_iter_rw(iter) == WRITE && !dio->wait_for_completion &&
!inode->i_sb->s_dio_done_wq) {
ret = sb_init_dio_done_wq(inode->i_sb);
if (ret < 0)
@@ -1717,8 +1717,10 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
iomap_dio_actor);
if (ret <= 0) {
/* magic error code to fall back to buffered I/O */
- if (ret == -ENOTBLK)
+ if (ret == -ENOTBLK) {
+ dio->wait_for_completion = true;
ret = 0;
+ }
break;
}
pos += ret;
@@ -1739,7 +1741,7 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
dio->flags &= ~IOMAP_DIO_NEED_SYNC;
if (!atomic_dec_and_test(&dio->ref)) {
- if (!is_sync_kiocb(iocb))
+ if (!dio->wait_for_completion)
return -EIOCBQUEUED;
for (;;) {
^ permalink raw reply related
* Re: [PATCH] audit: add containerid support for IMA-audit
From: Richard Guy Briggs @ 2018-05-18 15:51 UTC (permalink / raw)
To: Mimi Zohar
Cc: Stefan Berger, containers, Linux-Audit Mailing List,
linux-integrity, LKML, paul, sgrubb
In-Reply-To: <1526647996.3632.164.camel@linux.vnet.ibm.com>
On 2018-05-18 08:53, Mimi Zohar wrote:
> On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote:
> > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote:
>
> [...]
>
> > >>> auxiliary record either by being converted to a syscall auxiliary record
> > >>> by using current->audit_context rather than NULL when calling
> > >>> audit_log_start(), or creating a local audit_context and calling
> > >> ima_parse_rule() is invoked when setting a policy by writing it into
> > >> /sys/kernel/security/ima/policy. We unfortunately don't have the
> > >> current->audit_context in this case.
> > > Sure you do. What process writes to that file? That's the one we care
> > > about, unless it is somehow handed off to a queue and processed later in
> > > a different context.
> >
> > I just printk'd it again. current->audit_context is NULL in this case.
>
> The builtin policy rules are loaded at __init. Subsequently a custom
> policy can replace the builtin policy rules by writing to the
> securityfs file. Is the audit_context NULL in both cases?
I wondered the same.
> > >> If so, which ones? We could probably refactor the current
> > >> integrity_audit_message() and have ima_parse_rule() call into it to get
> > >> those fields as well. I suppose adding new fields to it wouldn't be
> > >> considered breaking user space?
> > > Changing the order of existing fields or inserting fields could break
> > > stuff and is strongly discouraged without a good reason, but appending
> > > fields is usually the right way to add information.
> > >
> > > There are exceptions, and in this case, I'd pick the "more standard" of
> > > the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and stick
> > > with that, abandoning the other format, renaming the less standard
> > > version of the record (ima_parse_rule?) and perhpas adopting that
> > > abandonned format for the new record type while using
> > > current->audit_context.
>
> This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> ima_audit_measurement(). Could we rename type=1805 to be
> INTEGRITY_AUDIT or INTEGRITY_IMA_AUDIT? The new type=1806 audit
> message could be named INTEGRITY_RULE or, if that would be confusing,
> INTEGRITY_POLICY_RULE.
I'm reluctant to change the macro/value. Just use the existing
AUDIT_INTEGRITY_RULE 1805 as appropriate and create a new
AUDIT_INTEGRITY_AUDIT 1806.
> > 1806 would be in sync with INTEGRITY_RULE now for process related info.
> > If this looks good, I'll remove the dependency on your local context
> > creation and post the series.
> >
> > The justification for the change is that the INTEGRITY_RULE, as produced
> > by ima_parse_rule(), is broken.
>
> Post which series? The IMA namespacing patch set? This change should
> be upstreamed independently of IMA namespacing.
>
> Mimi
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH] audit: add containerid support for IMA-audit
From: Richard Guy Briggs @ 2018-05-18 15:51 UTC (permalink / raw)
To: Mimi Zohar
Cc: paul-r2n+y4ga6xFZroRs9YW3xA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
Linux-Audit Mailing List, linux-integrity,
sgrubb-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1526647996.3632.164.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 2018-05-18 08:53, Mimi Zohar wrote:
> On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote:
> > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote:
>
> [...]
>
> > >>> auxiliary record either by being converted to a syscall auxiliary record
> > >>> by using current->audit_context rather than NULL when calling
> > >>> audit_log_start(), or creating a local audit_context and calling
> > >> ima_parse_rule() is invoked when setting a policy by writing it into
> > >> /sys/kernel/security/ima/policy. We unfortunately don't have the
> > >> current->audit_context in this case.
> > > Sure you do. What process writes to that file? That's the one we care
> > > about, unless it is somehow handed off to a queue and processed later in
> > > a different context.
> >
> > I just printk'd it again. current->audit_context is NULL in this case.
>
> The builtin policy rules are loaded at __init. Subsequently a custom
> policy can replace the builtin policy rules by writing to the
> securityfs file. Is the audit_context NULL in both cases?
I wondered the same.
> > >> If so, which ones? We could probably refactor the current
> > >> integrity_audit_message() and have ima_parse_rule() call into it to get
> > >> those fields as well. I suppose adding new fields to it wouldn't be
> > >> considered breaking user space?
> > > Changing the order of existing fields or inserting fields could break
> > > stuff and is strongly discouraged without a good reason, but appending
> > > fields is usually the right way to add information.
> > >
> > > There are exceptions, and in this case, I'd pick the "more standard" of
> > > the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and stick
> > > with that, abandoning the other format, renaming the less standard
> > > version of the record (ima_parse_rule?) and perhpas adopting that
> > > abandonned format for the new record type while using
> > > current->audit_context.
>
> This sounds right, other than "type=INTEGRITY_RULE" (1805) for
> ima_audit_measurement(). Could we rename type=1805 to be
> INTEGRITY_AUDIT or INTEGRITY_IMA_AUDIT? The new type=1806 audit
> message could be named INTEGRITY_RULE or, if that would be confusing,
> INTEGRITY_POLICY_RULE.
I'm reluctant to change the macro/value. Just use the existing
AUDIT_INTEGRITY_RULE 1805 as appropriate and create a new
AUDIT_INTEGRITY_AUDIT 1806.
> > 1806 would be in sync with INTEGRITY_RULE now for process related info.
> > If this looks good, I'll remove the dependency on your local context
> > creation and post the series.
> >
> > The justification for the change is that the INTEGRITY_RULE, as produced
> > by ima_parse_rule(), is broken.
>
> Post which series? The IMA namespacing patch set? This change should
> be upstreamed independently of IMA namespacing.
>
> Mimi
>
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/2] Add generic Nios II board.
From: Philippe Mathieu-Daudé @ 2018-05-18 15:50 UTC (permalink / raw)
To: Julian Brown, qemu-devel
Cc: Andrew Jenner, Marek Vašut, Marek Vašut, Chris Wulff
In-Reply-To: <651c4ec90c74a9ed34c5d200038de0e7c4ecc39c.1526595970.git.julian@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Hi Julian,
You should Cc the NiosII maintainers for faster review (done).
(From
https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer:)
$ ./scripts/get_maintainer.pl -f hw/nios2/
Chris Wulff <crwulff@gmail.com> (maintainer:NiosII)
Marek Vasut <marex@denx.de> (maintainer:NiosII)
On 05/17/2018 07:38 PM, Julian Brown wrote:
>
> This patch adds support for a generic MMU-less Nios II board that can
> be used e.g. for bare-metal compiler testing. Nios II booting is also
> tweaked so that bare-metal binaries start executing in RAM starting at
> 0x00000000, rather than an alias at 0xc0000000, which allows features
> such as unwinding to work when binaries are linked to start at the
> beginning of the address space.
>
> The generic_nommu.c parts are by Andrew Jenner, based on code by Marek
> Vasut.
Can you get/add their S-o-b?
> Signed-off-by: Julian Brown <julian@codesourcery.com>
> ---
> hw/nios2/Makefile.objs | 2 +-
> hw/nios2/boot.c | 5 +-
> hw/nios2/generic_nommu.c | 128 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 133 insertions(+), 2 deletions(-)
> create mode 100644 hw/nios2/generic_nommu.c
It seems your email client messed your patch up, see
https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment
Can you resend?
Regards,
Phil.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [SPDK] Working With bdevs/lvols
From: Gruher, Joseph R @ 2018-05-18 15:49 UTC (permalink / raw)
To: spdk
[-- Attachment #1: Type: text/plain, Size: 6563 bytes --]
This seems to be working well for me. To close the thread, here's the step I performed to create 64 20GiB lvols from 4 NVMe SSDs (16 lvols per):
#go to spdk working directory
cd spdk
#prepare to run SPDK
sudo scripts/setup.sh
#start SPDK with 16 cores
sudo app/nvmf_tgt/nvmf_tgt -m 0xFFFF0
#create bdevs from 4 NVMe devices
sudo ./rpc.py construct_nvme_bdev -b spdkdev1 -t pcie -a 0000:3d:00.0
sudo ./rpc.py construct_nvme_bdev -b spdkdev2 -t pcie -a 0000:3e:00.0
sudo ./rpc.py construct_nvme_bdev -b spdkdev3 -t pcie -a 0000:3f:00.0
sudo ./rpc.py construct_nvme_bdev -b spdkdev4 -t pcie -a 0000:40:00.0
#create 4 lvol stores from 4 NVMe bdevs
sudo ./rpc.py construct_lvol_store spdkdev1n1 lvolstore1
sudo ./rpc.py construct_lvol_store spdkdev2n1 lvolstore2
sudo ./rpc.py construct_lvol_store spdkdev3n1 lvolstore3
sudo ./rpc.py construct_lvol_store spdkdev4n1 lvolstore4
#create 16x 20GB lvols in each lvol store
sudo ./rpc.py construct_lvol_bdev -l lvolstore1 lvol01 20480
sudo ./rpc.py construct_lvol_bdev -l lvolstore1 lvol02 20480
<cut for length>
sudo ./rpc.py construct_lvol_bdev -l lvolstore4 lvol63 20480
sudo ./rpc.py construct_lvol_bdev -l lvolstore4 lvol64 20480
#Create new NVMeoF subsystem
sudo ./rpc.py construct_nvmf_subsystem -s "TESTSERIAL" -a nqn.2018-05.io.spdk:nqn01 "trtype:RDMA traddr:10.6.0.18 trsvcid:4420" ""
#Confirm subsystem exists
sudo nvme discover -t rdma -a 10.6.0.18
Discovery Log Number of Records 1, Generation counter 3
=====Discovery Log Entry 0======
trtype: rdma
adrfam: ipv4
subtype: nvme subsystem
treq: not specified
portid: 0
trsvcid: 4420
subnqn: nqn.2018-05.io.spdk:nqn01
traddr: 10.6.0.18
rdma_prtype: not specified
rdma_qptype: connected
rdma_cms: rdma-cm
rdma_pkey: 0x0000
#Add the 64 volumes to the subsystem
sudo ./rpc.py nvmf_subsystem_add_ns nqn.2018-05.io.spdk:nqn01 lvolstore1/lvol01
sudo ./rpc.py nvmf_subsystem_add_ns nqn.2018-05.io.spdk:nqn01 lvolstore1/lvol02
<cut for length>
sudo ./rpc.py nvmf_subsystem_add_ns nqn.2018-05.io.spdk:nqn01 lvolstore4/lvol63
sudo ./rpc.py nvmf_subsystem_add_ns nqn.2018-05.io.spdk:nqn01 lvolstore4/lvol64
#Connect subsystem using kernel initiator
sudo nvme connect -t rdma -a 10.6.0.18 -n nqn.2018-05.io.spdk:nqn01 -i 8
#Confirm volumes available on initiator
rsa(a)tppjoe01:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 86.6M 1 loop /snap/core/4486
sda 8:0 1 14.6G 0 disk
└─sda1 8:1 1 4.3G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 119.2G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
└─nvme0n1p2 259:2 0 118.8G 0 part /
nvme1n1 259:4 0 20G 0 disk
nvme1n2 259:6 0 20G 0 disk
<cut for length>
nvme1n63 259:128 0 20G 0 disk
nvme1n64 259:130 0 20G 0 disk
Now to run some IO...
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
> Sent: Thursday, May 17, 2018 1:06 PM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: Re: [SPDK] Working With bdevs/lvols
>
> Thanks Curt! These are great examples. A few comments inline:
>
>
> On 5/17/18, 12:59 PM, "SPDK on behalf of Bruns, Curt E" <spdk-
> bounces(a)lists.01.org on behalf of curt.e.bruns(a)intel.com> wrote:
>
> Hi Joe,
>
> I played with this just recently. Make sure when you start the nvmf_target,
> you also enable RPC listener (the -r parameter):
>
> [Jim] You shouldn’t have to specify –r, unless you want to override the default
> RPC domain socket location (/var/tmp/spdk.sock).
>
> <snip>
>
> % python rpc.py -s 100.100.1.82 -p 5260 construct_lvol_store AIO0
> lvol_store1
> 723221b4-b884-404d-a47e-946c7ffb6d7f # Make note of this UUID
>
> <snip>
>
> # Create a 100MB Thin provisioned volume on that LVOL_Store:
> % python rpc.py -s 100.100.1.82 -p 5260 construct_lvol_bdev -u 723221b4-
> b884-404d-a47e-946c7ffb6d7f -t vol1 100
> c008972d-68e8-4795-9896-dd09a8d7062a # Note this UUID
>
> # Create a new Subsystem
> % python rpc.py -s 100.100.1.82 -p 5260 construct_nvmf_subsystem -a -s
> "SPDKTEST" nqn.2016-06.io.spdk:cnodex "trtype:RDMA traddr:100.100.1.82
> trsvcid:4421" ""
>
> # Add vol1 to that Subsystem (using that UUID from thin-provisioned volume)
> % python rpc.py -s 100.100.1.82 -p 5260 nvmf_subsystem_add_ns nqn.2016-
> 06.io.spdk:cnodex c008972d-68e8-4795-9896-dd09a8d7062a
>
> You can use the alias (lvol_store1/vol1) instead of the full UUID as of SPDK
> v18.01.
> You can also combine these two steps by passing –n “lvol_store1/vol1” to the
> construct_nvmf_subsystem RPC.
>
> <snip>
>
> On 5/17/18, 12:46 PM, "SPDK on behalf of Gruher, Joseph R" <spdk-
> bounces(a)lists.01.org on behalf of joseph.r.gruher(a)intel.com> wrote:
>
> >>>> rpc.py sends RPCs to a running SPDK target application. The target
> application will create this /var/tmp/spdk.sock Unix domain socket. Is it
> possible that the nvmf_tgt process hasn’t been started yet when sending the
> construct_nvme_bdev RPC?
>
> Yes, I haven't started nvmf_tgt. I guess the process I was looking for was:
> 1) create bdevs
> 2) create lvol store
> 3) create lvols
> 4) start nvmf_tgt with subsystem configuration defined in nvmf.conf.in
> that uses lvolvs
>
> It sounds like what I need to do instead is:
> 1) start nvmf_tgt
> 2) create bdevs
> 3) create lvol store
> 4) create lvols
>
> My question then is, how do I create my subsystems? I'm not seeing a
> command line way to create subsystems in the documentation, just
> nvmf.conf.in. Is there a way to load a new nvmf.conf.in without stopping the
> target? Or how do I go about creating the subsystems if the target is already
> running?
>
> Thanks,
> Joe
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
>
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
>
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
^ permalink raw reply
* Re: [LSFMM] RDMA data corruption potential during FS writeback
From: Jason Gunthorpe @ 2018-05-18 15:49 UTC (permalink / raw)
To: Christopher Lameter; +Cc: linux-rdma, linux-mm, Michal Hocko
In-Reply-To: <0100016373af827b-e6164b8d-f12e-4938-bf1f-2f85ec830bc0-000000@email.amazonses.com>
On Fri, May 18, 2018 at 02:37:52PM +0000, Christopher Lameter wrote:
> There was a session at the Linux Filesystem and Memory Management summit
> on issues that are caused by devices using get_user_pages() or elevated
> refcounts to pin pages and then do I/O on them.
>
> See https://lwn.net/Articles/753027/
>
> Basically filesystems need to mark the pages readonly during writeback.
> Concurrent DMA into the page while it is written by a filesystem can cause
> corrupted data being written to the disk, cause incorrect checksums etc
> etc.
>
> The solution that was proposed at the meeting was that mmu notifiers can
> remedy that situation by allowing callbacks to the RDMA device to ensure
> that the RDMA device and the filesystem do not do concurrent writeback.
This keeps coming up, and I understand why it seems appealing from the
MM side, but the reality is that very little RDMA hardware supports
this, and it carries with it a fairly big performance penalty so many
users don't like using it.
> This issue has been around for a long time and so far not caused too much
> grief it seems. Doing I/O to two devices from the same memory location is
> naturally a bit inconsistent in itself.
Well, I've seen various reports of FS's oopsing and what not, as the
LWN article points out.. So it is breaking stuff for some users.
> But could we do more to prevent issues here? I think what may be useful is
> to not allow the memory registrations of file back writable mappings
> unless the device driver provides mmu callbacks or something like that.
Why does every proposed solution to this involve crippling RDMA? Are
there really no ideas no ideas to allow the FS side to accommodate
this use case??
> There may even be more issues if DAX is being used but the FS writeback
> has the potential of biting anyone at this point it seems.
I think Dan already 'solved' this via get_user_pages_longterm which
just fails for DAX backed pages.
Jason
^ permalink raw reply
* Re: [PATCH v3] NFC: pn533: don't send USB data off of the stack
From: Johan Hovold @ 2018-05-18 15:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arend van Spriel, Carlos Manuel Santos, Samuel Ortiz,
Stephen Hemminger, linux-usb, linux-wireless
In-Reply-To: <20180518103811.GA29186@kroah.com>
On Fri, May 18, 2018 at 12:38:11PM +0200, Greg Kroah-Hartman wrote:
> It's amazing that this driver ever worked, but now that x86 doesn't
> allow USB data to be sent off of the stack, it really does not work at
> all. Fix this up by properly allocating the data for the small
> "commands" that get sent to the device.
>
> The USB stack will free the buffer when the data has been transmitted,
> that is why there is no kfree() to mirror the call to kmalloc().
It looks like you're now leaking all but the final transfer buffer that
is allocated for outgoing commands, as the URBs themselves are not freed
until disconnect() (and that's when core would free the buffers along
with the URBs if URB_FREE_BUFFER is set).
Johan
^ permalink raw reply
* [Bug 106561] ./libdrm_macros.h:26:5: error: 'HAVE_VISIBILITY' is not defined, evaluates to 0 [-Werror,-Wundef]
From: bugzilla-daemon @ 2018-05-18 15:49 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106561-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1249 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106561
--- Comment #1 from Eric Engestrom <fdo-bugs@engestrom.ch> ---
Hi Tomasz,
I found this file; is that what you used to configure and compile libdrm?
https://abf.io/openmandriva/libdrm/blob/master/libdrm.spec
You seem to be using autotools, which is deprecated and will one day go away;
you should convert to Meson eventually, although I don't think this would
change anything with regards to your issue here.
We have a short page explaining how to use Meson on the Mesa website:
https://mesa3d.org/meson.html
The errors you're seeing are very strange; HAVE_VISIBILITY and UDEV are always
defined (by the build system) as far as I can tell, and the enum conversion
warnings are technically correct (although the value are identical, so it
should be trivial to fix), but this code hasn't been touched since 2009/1999.
Has any previous version of libdrm ever built in your build/packaging system?
For the last error, vasprintf() is a GNU extension, so I'm not surprised it's
not working with clang; I'll have a look next week to see if I can fix it the
way we did in Mesa (src/util/u_string.h).
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2249 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH for-next 4/5] tools: load IPXE from standalone file
From: Jan Beulich @ 2018-05-18 15:49 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, Ian Jackson, xen-devel
In-Reply-To: <20180515182243.3339-5-wei.liu2@citrix.com>
>>> On 15.05.18 at 20:22, <wei.liu2@citrix.com> wrote:
> @@ -95,13 +97,17 @@ static void rombios_load_roms(void)
> etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
> etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
> - etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
> - etherboot_phys_addr,
> - etherboot);
>
> - option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> - option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
> - option_rom_phys_addr);
> + if ( ipxe_module_addr )
> + {
> + etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
> + etherboot_phys_addr,
> + ipxe_module_addr);
> +
> + option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> + option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
> + option_rom_phys_addr);
> + }
I guess you want to alter existing logic as little as possible, hence you
don't want to leverage the fact that you (could) get the size passed ...
> @@ -133,6 +139,9 @@ static void rombios_load(const struct bios_config *config,
>
> info = (struct rombios_info *)BIOS_INFO_PHYSICAL_ADDRESS;
> info->bios32_entry = bioshigh;
> +
> + /* Stash ipxe address */
> + ipxe_module_addr = ipxe_addr;
> }
... here (but you ignore it). If the size was used, scan_option_rom() could be
made not even look at non-option-ROMs.
But on the basis that you simply retain existing functionality
Acked-by: Jan Beulich <jbeulich@suse.com>
for the hvmloader parts.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v4 27/49] tests/tcg: enable building for ARM
From: Alex Bennée @ 2018-05-18 15:48 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: cota, famz, berrange, richard.henderson, balrogg, aurelien, agraf,
Peter Maydell, qemu-devel, open list:ARM
In-Reply-To: <13cbc8f7-ed4b-e302-3a6c-b8791a21047b@amsat.org>
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> On 05/17/2018 02:46 PM, Alex Bennée wrote:
>> This allows us to use the docker cross compiler image to build these
>> tests.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>> tests/tcg/arm/Makefile.include | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>> create mode 100644 tests/tcg/arm/Makefile.include
>>
>> diff --git a/tests/tcg/arm/Makefile.include b/tests/tcg/arm/Makefile.include
>> new file mode 100644
>> index 0000000000..8e7eac008f
>> --- /dev/null
>> +++ b/tests/tcg/arm/Makefile.include
>> @@ -0,0 +1,8 @@
>> +# Makefile.include for all ARM targets
>> +#
>> +# We don't have any bigendian build tools so we only use this for armhf
>> +
>> +ifeq ($(TARGET_NAME),arm)
>> +DOCKER_IMAGE=debian-armhf-cross
>
> [Note for a later series:]
> Since this image comes with ARMv7 libraries, I find clearer to rename as
> arm32v7, following new Docker scheme. This will ease to add arm32v6 (and
> arm32v5 if possible...)
I'm not sure if that is worthwhile. Any linux-user build will be ARMv7
or v8 AArch32 and the compilers can always be set to older CPU types.
Testing that we have correct UNDEF behaviour for older CPUs is probably
better handled by things like RISU?
>
>> +DOCKER_CROSS_COMPILER=arm-linux-gnueabihf-gcc
>> +endif
>>
>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
--
Alex Bennée
^ permalink raw reply
* [v3] NFC: pn533: don't send USB data off of the stack
From: Johan Hovold @ 2018-05-18 15:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arend van Spriel, Carlos Manuel Santos, Samuel Ortiz,
Stephen Hemminger, linux-usb, linux-wireless
On Fri, May 18, 2018 at 12:38:11PM +0200, Greg Kroah-Hartman wrote:
> It's amazing that this driver ever worked, but now that x86 doesn't
> allow USB data to be sent off of the stack, it really does not work at
> all. Fix this up by properly allocating the data for the small
> "commands" that get sent to the device.
>
> The USB stack will free the buffer when the data has been transmitted,
> that is why there is no kfree() to mirror the call to kmalloc().
It looks like you're now leaking all but the final transfer buffer that
is allocated for outgoing commands, as the URBs themselves are not freed
until disconnect() (and that's when core would free the buffers along
with the URBs if URB_FREE_BUFFER is set).
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.