* Re: [PATCH 05/22] audit: Fix sleep in atomic
From: Jan Kara @ 2017-01-04 8:50 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, linux-fsdevel, Amir Goldstein, Lino Sanfilippo,
Miklos Szeredi, linux-audit
In-Reply-To: <CAHC9VhTarSPE2QZ8xMdwmQ=r_2f0KL8Mum6PtrSEyEVPuq_gjg@mail.gmail.com>
On Tue 03-01-17 16:11:16, Paul Moore wrote:
> On Mon, Jan 2, 2017 at 1:21 PM, Jan Kara <jack@suse.cz> wrote:
> > So I found where the problem was. Attached is a new version of the patch.
> > Tests from audit-testsuite fail for me but do not hang anymore. I guess the
> > failing is because I don't have audit or selinux configured in any way and
> > I'm using SUSE I guess (if there's some easy way to do that, I'd be
> > interested) - runtests.pl complains that I have to be root although I am...
>
> I've never tried running the tests on SUSE, but if audit and SELinux
> are in some undetermined state, then I can only imagine what wierd
> test results you would get.
Well, the state is well determined - nothing is installed ;) I was kind of
hoping kernel support would be enough but apparently the testsuite needs
some userspace installed & configured as well.
> I'm building a test kernel as I type this, I'll report back when I have
> some results.
Thanks!
> Also, while I'm sure you've heard this before (and likely already know
> better), please send patches inline, it makes review/commenting much
> easier.
Actually, I haven't heard this for quite a long time :) and I myself
prefer attached patches (with text/plain attachment type) when they are
in a reply to another email - they are easier to extract and at least my
mail client automatically inlines them when I hit reply... Arguably the
best of both worlds is to use git-send-email with properly set threading
but I tend to forget about that option.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] drm/atomic-helper: roll out commit synchronization
From: Daniel Vetter @ 2017-01-04 8:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Daniel Vetter, Tomeu Vizoso, Daniel Stone, dri-devel,
Daniel Vetter
In-Reply-To: <4882813.aDmsgc3lL8@avalon>
On Mon, Jan 02, 2017 at 02:09:13PM +0200, Laurent Pinchart wrote:
> On Wednesday 08 Jun 2016 17:15:36 Daniel Vetter wrote:
> > +void drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_crtc_commit *commit;
> > + int i;
> > + long ret;
> > +
> > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > + commit = state->crtcs[i].commit;
> > + if (WARN_ON(!commit))
> > + continue;
> > +
> > + spin_lock(&crtc->commit_lock);
> > + complete_all(&commit->cleanup_done);
> > + WARN_ON(!try_wait_for_completion(&commit->hw_done));
> > +
> > + /* commit_list borrows our reference, need to remove before we
> > + * clean up our drm_atomic_state. But only after it actually
> > + * completed, otherwise subsequent commits won't stall
> properly. */
> > + if (try_wait_for_completion(&commit->flip_done)) {
> > + list_del(&commit->commit_entry);
> > + spin_unlock(&crtc->commit_lock);
> > + continue;
> > + }
> > +
> > + spin_unlock(&crtc->commit_lock);
> > +
> > + /* We must wait for the vblank event to signal our completion
> > + * before releasing our reference, since the vblank work does
> > + * not hold a reference of its own. */
> > + ret = wait_for_completion_timeout(&commit->flip_done,
> > + 10*HZ);
>
> Why is this needed ? drm_atomic_helper_commit_cleanup_done() is called in
> commit_tail() after the call to drm_atomic_helper_commit_tail() or to the
> driver's .atomic_commit_tail() handler. If I'm not mistaken both already wait
> for the page flip to complete, either with a call to
> drm_atomic_helper_wait_for_vblanks() in drm_atomic_helper_commit_tail() or
> with a custom method in the driver's .atomic_commit_tail() handler.
You might still race with the event handling, and for legacy cursor
updates we've ommitted the vblank waits. Anyway there's a patch from me on
the m-l to switch over to refcounting, which makes this code here
unecessary. I guess I should apply it to drm-misc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: RFC: fb restore on drm master close
From: vcaputo @ 2017-01-04 8:48 UTC (permalink / raw)
To: St??phane Marchesin; +Cc: dri-devel@lists.freedesktop.org
In-Reply-To: <CACP_E++OSGaMQ_ADYeWTZDaX5fhW86P5ro2ABcktCmOCEs0UfQ@mail.gmail.com>
On Wed, Jan 04, 2017 at 12:38:04AM -0800, St??phane Marchesin wrote:
> On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@pengaru.com wrote:
> >> Hello list,
> >>
> >> I've been playing with an unaccelerated drm program[1] and have been
> >> annoyed that whenever this program exits the fbcon isn't restored, with
> >> the display left completely off.
> >>
> >> This seems to happen because Xorg is still running from a different VT.
> >>
> >> Upon further investigation, it seems like the fb restore only occurs on
> >> "lastclose", which explains what I'm observing.
> >>
> >> Why don't we perform the fb restore whenever the current master is
> >> closed to cover this case, since masters are the ones that can change
> >> modes?
>
> One case where it's useful not to do this is the handoff from a splash
> screen to a display server.
>
If the handoff is avoiding the existing lastclose semantics somehow by
having overlapping opens, couldn't drmDropMaster() be employed to avoid
the masterclose restore when the splash screen closes?
Regards,
Vito Caputo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Qemu-devel] NBD handshake may block qemu main thread when socket delays or has packet loss
From: Fangyi (C) @ 2017-01-04 8:45 UTC (permalink / raw)
To: kwolf, mreitz, pbonzini
Cc: wu.wubin, eblake, qemu-block, qemu-devel, subo7, lina.lulina,
jiangxiaoqing (C)
As we all know, socket is in blocking mode when nbd is negotiating
with the other end. If the network is poor because of delay or packet
loss, socket read or write will return very slowly. The mainloop events
won't be handled in time util nbd handshake ends.
Any advices to solve the problem?
Thanks,
Regards,
FANG Yi.
^ permalink raw reply
* Re: [PATCH, REGRESSION] ubifs: fix unencrypted journal write
From: Peter Rosin @ 2017-01-04 8:47 UTC (permalink / raw)
To: Richard Weinberger, linux-kernel
Cc: Artem Bityutskiy, Adrian Hunter, David Gstir, linux-mtd
In-Reply-To: <1483519109-26279-1-git-send-email-peda@axentia.se>
On 2017-01-04 09:38, Peter Rosin wrote:
> Without this, I get the following on reboot:
>
> UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad target node (type 1) length (8240)
> UBIFS error (ubi1:0 pid 703): ubifs_load_znode: have to be in range of 48-4144
> UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad indexing node at LEB 13:11080, error 5
> magic 0x6101831
> crc 0xb1cb246f
> node_type 9 (indexing node)
> group_type 0 (no node group)
> sqnum 546
> len 128
> child_cnt 5
> level 0
> Branches:
> 0: LEB 14:72088 len 161 key (133, inode)
> 1: LEB 14:81120 len 160 key (134, inode)
> 2: LEB 20:26624 len 8240 key (134, data, 0)
> 3: LEB 14:81280 len 160 key (135, inode)
> 4: LEB 20:34864 len 8240 key (135, data, 0)
> UBIFS warning (ubi1:0 pid 703): ubifs_ro_mode.part.0: switched to read-only mode, error -22
> CPU: 0 PID: 703 Comm: mount Not tainted 4.9.0-next-20161213+ #1197
To be clear, this log is from next-20161213 plus the ubifs patches that
appeared in next-20161214. The problem remains on v4.10-rc2
Cheers,
peda
> Hardware name: Atmel SAMA5
> [<c010d2ac>] (unwind_backtrace) from [<c010b250>] (show_stack+0x10/0x14)
> [<c010b250>] (show_stack) from [<c024df94>] (ubifs_jnl_update+0x2e8/0x614)
> [<c024df94>] (ubifs_jnl_update) from [<c0254bf8>] (ubifs_mkdir+0x160/0x204)
> [<c0254bf8>] (ubifs_mkdir) from [<c01a6030>] (vfs_mkdir+0xb0/0x104)
> [<c01a6030>] (vfs_mkdir) from [<c0286070>] (ovl_create_real+0x118/0x248)
> [<c0286070>] (ovl_create_real) from [<c0283ed4>] (ovl_fill_super+0x994/0xaf4)
> [<c0283ed4>] (ovl_fill_super) from [<c019c394>] (mount_nodev+0x44/0x9c)
> [<c019c394>] (mount_nodev) from [<c019c4ac>] (mount_fs+0x14/0xa4)
> [<c019c4ac>] (mount_fs) from [<c01b5338>] (vfs_kern_mount+0x4c/0xd4)
> [<c01b5338>] (vfs_kern_mount) from [<c01b6b80>] (do_mount+0x154/0xac8)
> [<c01b6b80>] (do_mount) from [<c01b782c>] (SyS_mount+0x74/0x9c)
> [<c01b782c>] (SyS_mount) from [<c0107f80>] (ret_fast_syscall+0x0/0x3c)
> UBIFS error (ubi1:0 pid 703): ubifs_mkdir: cannot create directory, error -22
> overlayfs: failed to create directory /mnt/ovl/work/work (errno: 22); mounting read-only
>
> Fixes: 7799953b34d1 ("ubifs: Implement encrypt/decrypt for all IO")
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> fs/ubifs/journal.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index a459211a1c21..a7932dcb2fc7 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -744,6 +744,7 @@ int ubifs_jnl_write_data(struct ubifs_info *c, const struct inode *inode,
>
> } else {
> data->compr_size = 0;
> + out_len = compr_len;
> }
>
> dlen = UBIFS_DATA_NODE_SZ + out_len;
>
^ permalink raw reply
* Re: [PATCH v3 2/4] net/e1000: add firmware version get
From: Ferruh Yigit @ 2017-01-04 8:47 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC990A@SHSMSX101.ccr.corp.intel.com>
On 1/4/2017 3:14 AM, Yang, Qiming wrote:
> See the reply below.
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 11:03 PM
> To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>
> Subject: Re: [PATCH v3 2/4] net/e1000: add firmware version get
>
> On 12/27/2016 12:30 PM, Qiming Yang wrote:
>> This patch adds a new function eth_igb_fw_version_get.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> v3 changes:
>> * use eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
>> u32 *fw_minor, u32 *fw_minor, u32 *fw_patch, u32 *etrack_id) instead
>> of eth_igb_fw_version_get(struct rte_eth_dev *dev, char *fw_version,
>> int fw_length). Add statusment in /doc/guides/nics/features/igb.ini.
>> ---
>> ---
>> doc/guides/nics/features/igb.ini | 1 +
>> drivers/net/e1000/igb_ethdev.c | 43 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 44 insertions(+)
>>
>> diff --git a/doc/guides/nics/features/igb.ini
>> b/doc/guides/nics/features/igb.ini
>> index 9fafe72..ffd87ba 100644
>> --- a/doc/guides/nics/features/igb.ini
>> +++ b/doc/guides/nics/features/igb.ini
>> @@ -39,6 +39,7 @@ EEPROM dump = Y
>> Registers dump = Y
>> BSD nic_uio = Y
>> Linux UIO = Y
>> +FW version = Y
>
> Please keep same location with default.ini file. Why you are putting this just into middle of the uio and vfio?
> Qiming: It's a clerical error, I want to add this line at the end of this file.
>
>> Linux VFIO = Y
>> x86-32 = Y
>> x86-64 = Y
>> diff --git a/drivers/net/e1000/igb_ethdev.c
>> b/drivers/net/e1000/igb_ethdev.c index 4a15447..25344b7 100644
>> --- a/drivers/net/e1000/igb_ethdev.c
>> +++ b/drivers/net/e1000/igb_ethdev.c
>> @@ -120,6 +120,8 @@ static int eth_igb_xstats_get_names(struct rte_eth_dev *dev,
>> unsigned limit);
>> static void eth_igb_stats_reset(struct rte_eth_dev *dev); static
>> void eth_igb_xstats_reset(struct rte_eth_dev *dev);
>> +static void eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
>> + u32 *fw_minor, u32 *fw_patch, u32 *etrack_id);
>
> I think you can use a struct as parameter here. But beware, that struct should NOT be a public struct.
> Qiming: I think only add a private struct for igb is unnecessary. Keep the arguments consistent with rte_eth_dev_fw_info_get is better.
> What do you think?
Both are OK.
Normally, I believe using struct is better. But we are not using struct
in public API because of the ABI compatibility issues. Here it is
internal usage, there is no ABI breakage concern, so it may be possible
to use a struct.
But if you prefer to keep the arguments same here with public API, that
is fine.
>
>> static void eth_igb_infos_get(struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info); static const uint32_t
>> *eth_igb_supported_ptypes_get(struct rte_eth_dev *dev); @@ -389,6
>> +391,7 @@ static const struct eth_dev_ops eth_igb_ops = {
>> .xstats_get_names = eth_igb_xstats_get_names,
>> .stats_reset = eth_igb_stats_reset,
>> .xstats_reset = eth_igb_xstats_reset,
>> + .fw_version_get = eth_igb_fw_version_get,
>> .dev_infos_get = eth_igb_infos_get,
>> .dev_supported_ptypes_get = eth_igb_supported_ptypes_get,
>> .mtu_set = eth_igb_mtu_set,
>> @@ -1981,6 +1984,46 @@ eth_igbvf_stats_reset(struct rte_eth_dev *dev)
>> }
>>
>
> <...>
>
^ permalink raw reply
* Re: Unix Device Memory Allocation project
From: Stéphane Marchesin @ 2017-01-04 8:46 UTC (permalink / raw)
To: Marek Olšák; +Cc: James Jones, dri-devel
In-Reply-To: <CAAxE2A4EVqtBk7+hEURtLcHaEH7OCNnA=H3T74J-zqUqAOX53g@mail.gmail.com>
On Tue, Jan 3, 2017 at 3:38 PM, Marek Olšák <maraeo@gmail.com> wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák <maraeo@gmail.com> wrote:
>>>>> We've had per buffer metadata in Radeon since KMS, which I believe first
>>>>> appeared in 2009. It's 4 bytes large and is used to communicate tiling
>>>>> flags between Mesa, DDX, and the kernel display code. It was a widely
>>>>> accepted solution back then and Red Hat was the main developer. So yeah,
>>>>> pretty much all people except Intel were collaborating on "sneaking" this
>>>>> in in 2009. I think radeon driver developers deserve an apology for that
>>>>> language.
>>>>>
>>>>> Amdgpu extended that metadata to 8 bytes and it's used in the same way as
>>>>> radeon. Additionally, amdgpu added opaque metadata having 256 bytes for use
>>>>> by userspace drivers only. The kernel driver isn't supposed to read it or
>>>>> parse it. The format is negotiated between userspace driver developers for
>>>>> sharing of more complex allocations than 2D displayable surfaces.
>>>>
>>>> Metadata needed for kms (what Christian also pointed out) is what everyone
>>>> did (intel included) and I think that's perfectly reasonable. And I was
>>>> aware of that radeon is doing that since the dawn of ages since forever.
>>>>
>>>> What I think is not really ok is opaque metadata blobs that the kernel
>>>> never ever inspect, but just carries around. That essentially means you're
>>>> reimplementing some bad form of IPC, and I dont think that's something the
>>>> drm subsystem (or dma-buf) really should be doing. Because you still have
>>>> that real protocol in userspace (dri2/3, wayland, whatever), but now with
>>>> a side channel with no documented ordering and synchronization. It gets
>>>> the job done for single-vendor buffer metadata transport, but as soon as
>>>> there's more than one vendor, or as soon as you need to reallocate buffers
>>>> dynamically because the usage changes it gets bad imo (and I've seen what
>>>
>>> The metadata is immutable after allocation, so it's not a
>>> communication channel. There is no synchronization or ordering needed
>>> for immutable metadata. That implies that a shared buffer can't be
>>> reused for an entirely different purpose. It can only be used as-is or
>>> freed.
>>>
>>> For suballocated memory, the idea is to reallocate it as a separate
>>> buffer on the first "handle" export, so that shared suballocated
>>> buffers don't exist.
>>
>> Yeah, once it becomes mutable the fun starts imo. I didn't realize
>> that you're treating it strictly immutable since at least the kernel
>> ioctl has both set and get (and that's the thing I looked at).
>> Immutable stuff shouldn't be any problem (except that of course it
>> won't work cross-driver in any fashion)
>>
>>>> that looks like on android in various forms). And that consensus (at least
>>>> among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
>>>> meeting we've had over 5 years ago. Not sure we're gaining anything with a
>>>> "who's older" competition.
>>>>
>>>> Anyways it's there and it's uabi so will never disappear. Just wanted to
>>>> make sure it's clear that for dma-buf we've discussed this years ago, and
>>>> decided it wasn't a great idea. And I think that's still correct.
>>>
>>> The arguments against blob metadata sound reasonable to me. I'm pretty
>>> sceptic that window system protocols will make driver-specific
>>> metadata blobs redundant anytime soon though. It seems the protocols
>>> don't get much attention nowadays and there is no incentive to do
>>> things differently in that area. At least that's how it appears to me,
>>> but I'm not involved in that.
>>
>> Folks are working on protocols again, at least I think the plan is to
>> make all that shared buffer allocation dance also work over
>> compositor/client situation (would be a bit pointless without that).
>> And agreed there'll always be driver-specific stuff which is opaque to
>> everyone else, but I hope at least in the future that all gets
>> shuffled around through protocol extensions. And not in the way every
>> Android gfx stack seems to work, where everyone has their own
>> vendor-private ipc-over-dma-buf thing. Wayland definitely got this
>> right, both protocol versioning and being able to add any kind of
>> new/vendor-private protocol endpoints to any wayland protocol. X is a
>> lot more pain, but since it finally looks like the world is switching
>> away from it we might get away with a simpler protocol there. At
>> least all the tricky reallocation dances seem to matter a lot more on
>> mobile/tablets/phones, and there Wayland starts to rule.
>
> I've been thinking about it, and it looks like we're gonna continue
> using immutable per-BO metadata (buffer layout, tiling description,
> compression flags). The reasons are that everything else is less
> economical, and the current "modifier" work done in EGL/GBM is
> insufficient for our hardware - we need approx. 96 bytes of metadata
> for proper buffer sharing (not just for display, but also 3D interop -
> MSAA, mipmapping, compression), while EGL modifiers only support 8
> bytes of metadata. However, that doesn't matter, because:
>
> These are the components that need to work with the BO metadata:
> - Mesa driver backend
> - AMDGPU kernel driver
>
> These are the components that should never know about the BO metadata:
> - Any Mesa shared code
> - EGL
> - GBM
> - Window system protocols
> - Display servers
> - DDXs
>
> The more components you need to change when the requirements change,
> the less economical the whole thing is, and the more painful the
> deployment is.
While you are right in a world where only AMDGPU exists, once you
start doing interop things fall apart. Common examples include
exporting a buffer to an external consumer that requires a certain
format (for example if you're displaying with UDL).
>
> Interop with other vendors would be trivial - the kernel drivers can
> exchange buffer layouts, and DRM can have an interface for it.
It's not just DRM, there are other consumers of dmabuf like v4l2. I
agree that you could move the negotiation in the kernel, but this
seems more complicated and less flexible. In short: if it doesn't need
to be in the kernel, it probably shouldn't be.
> Userspace doesn't have to know about any of that. (It also seems kinda
> dangerous to use userspace as a middle man for passing the
> metadata/modifiers around)
I don't think that's an issue in practice... If the app decides to
corrupt its own rendering, meh.
Stéphane
>
> Speaking of compression for display, especially the separate
> compression buffer: That should be fully contained in the main DMABUF
> and described by the per-BO metadata. Some other drivers want to use a
> separate DMABUF for the compression buffer - while that may sound good
> in theory, it's not economical for the reason described above.
>
> Marek
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v3 2/3] x86/64: Introduce a new constant KERNEL_MAPPING_SIZE
From: Baoquan He @ 2017-01-04 8:37 UTC (permalink / raw)
To: tglx, hpa, mingo
Cc: linux-kernel, x86, keescook, yinghai, bp, thgarnie, kuleshovmail,
luto, mcgrof, anderson, dyoung, Baoquan He
In-Reply-To: <1483519053-23402-1-git-send-email-bhe@redhat.com>
In x86, KERNEL_IMAGE_SIZE is used to limit the size of kernel image in
running space, but also represents the size of kernel image mapping area.
This looks good when kernel virtual address is invariable inside 512M
area and kernel image size is not bigger than 512M.
Along with the adding of kaslr, in x86_64 the area of kernel mapping is
extended up another 512M. It becomes improper to let KERNEL_IMAGE_SIZE
alone still play two roles now.
So introduce a new constant KERNEL_MAPPING_SIZE to represent the size of
kernel mapping area in x86_64. Let KERNEL_IMAGE_SIZE be as its name is
saying.
In this patch, just add KERNEL_MAPPING_SIZE and replace KERNEL_IMAGE_SIZE
with it in the relevant places. No functional change.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
---
arch/x86/boot/compressed/kaslr.c | 20 +++++++++++++++-----
arch/x86/include/asm/page_64_types.h | 17 ++++++++++++-----
arch/x86/include/asm/pgtable_64_types.h | 2 +-
arch/x86/kernel/head_64.S | 3 ++-
arch/x86/mm/physaddr.c | 6 +++---
5 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index a66854d..6ded03b 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -22,6 +22,12 @@
static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+/*
+ * By default, the size of kernel text mapping equals KERNEL_IMAGE_SIZE.
+ * While x86_64 may extend it to 1G if KASLR is enabled.
+ */
+static unsigned long _kernel_mapping_size = KERNEL_IMAGE_SIZE;
+
static unsigned long rotate_xor(unsigned long hash, const void *area,
size_t size)
{
@@ -311,7 +317,7 @@ static void process_e820_entry(struct e820entry *entry,
return;
/* On 32-bit, ignore entries entirely above our maximum. */
- if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
+ if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= _kernel_mapping_size)
return;
/* Ignore entries entirely below our minimum. */
@@ -341,8 +347,8 @@ static void process_e820_entry(struct e820entry *entry,
/* On 32-bit, reduce region size to fit within max size. */
if (IS_ENABLED(CONFIG_X86_32) &&
- region.start + region.size > KERNEL_IMAGE_SIZE)
- region.size = KERNEL_IMAGE_SIZE - region.start;
+ region.start + region.size > _kernel_mapping_size)
+ region.size = _kernel_mapping_size - region.start;
/* Return if region can't contain decompressed kernel */
if (region.size < image_size)
@@ -408,9 +414,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum,
/*
* There are how many CONFIG_PHYSICAL_ALIGN-sized slots
* that can hold image_size within the range of minimum to
- * KERNEL_IMAGE_SIZE?
+ * _kernel_mapping_size?
*/
- slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
+ slots = (_kernel_mapping_size - minimum - image_size) /
CONFIG_PHYSICAL_ALIGN + 1;
random_addr = kaslr_get_random_long("Virtual") % slots;
@@ -438,6 +444,10 @@ void choose_random_location(unsigned long input,
return;
}
+#ifdef CONFIG_X86_64
+ _kernel_mapping_size = KERNEL_MAPPING_SIZE;
+#endif
+
boot_params->hdr.loadflags |= KASLR_FLAG;
/* Prepare to add new identity pagetables on demand. */
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 62a20ea..20a5a9b 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -49,18 +49,25 @@
#define __PHYSICAL_MASK_SHIFT 46
#define __VIRTUAL_MASK_SHIFT 47
+
+/*
+ * Kernel image size is limited to 512 MB. The kernel code+data+bss
+ * must not be bigger than that.
+ */
+#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
+
/*
- * Kernel image size is limited to 1GiB due to the fixmap living in the
- * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
- * 512MiB by default, leaving 1.5GiB for modules once the page tables
+ * Kernel mapping size is limited to 1GiB due to the fixmap living in
+ * the next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S).
+ * Use 512MiB by default, leaving 1.5GiB for modules once the page tables
* are fully set up. If kernel ASLR is configured, it can extend the
* kernel page table mapping, reducing the size of the modules area.
*/
#define KERNEL_MAPPING_SIZE_EXT (1024 * 1024 * 1024)
#if defined(CONFIG_RANDOMIZE_BASE)
-#define KERNEL_IMAGE_SIZE KERNEL_MAPPING_SIZE_EXT
+#define KERNEL_MAPPING_SIZE KERNEL_MAPPING_SIZE_EXT
#else
-#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
+#define KERNEL_MAPPING_SIZE KERNEL_IMAGE_SIZE
#endif
#endif /* _ASM_X86_PAGE_64_DEFS_H */
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 3a26420..a357050 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -66,7 +66,7 @@ typedef struct { pteval_t pte; } pte_t;
#define VMEMMAP_START __VMEMMAP_BASE
#endif /* CONFIG_RANDOMIZE_MEMORY */
#define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
-#define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#define MODULES_VADDR (__START_KERNEL_map + KERNEL_MAPPING_SIZE)
#define MODULES_END _AC(0xffffffffff000000, UL)
#define MODULES_LEN (MODULES_END - MODULES_VADDR)
#define ESPFIX_PGD_ENTRY _AC(-2, UL)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 03bcb67..7446055 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -466,7 +466,8 @@ NEXT_PAGE(level2_kernel_pgt)
* 512M if no kaslr, 1G if kaslr enabled. Later cleanup_highmap will
* clean up those unused entries.
*
- * The module area starts after kernel mapping area.
+ * The module area starts after kernel mapping area, see MODULES_VADDR.
+ * It will vary with KERNEL_MAPPING_SIZE.
*/
PMDS(0, __PAGE_KERNEL_LARGE_EXEC,
PTRS_PER_PMD)
diff --git a/arch/x86/mm/physaddr.c b/arch/x86/mm/physaddr.c
index cfc3b91..c0b70fc 100644
--- a/arch/x86/mm/physaddr.c
+++ b/arch/x86/mm/physaddr.c
@@ -18,7 +18,7 @@ unsigned long __phys_addr(unsigned long x)
if (unlikely(x > y)) {
x = y + phys_base;
- VIRTUAL_BUG_ON(y >= KERNEL_IMAGE_SIZE);
+ VIRTUAL_BUG_ON(y >= KERNEL_MAPPING_SIZE);
} else {
x = y + (__START_KERNEL_map - PAGE_OFFSET);
@@ -35,7 +35,7 @@ unsigned long __phys_addr_symbol(unsigned long x)
unsigned long y = x - __START_KERNEL_map;
/* only check upper bounds since lower bounds will trigger carry */
- VIRTUAL_BUG_ON(y >= KERNEL_IMAGE_SIZE);
+ VIRTUAL_BUG_ON(y >= KERNEL_MAPPING_SIZE);
return y + phys_base;
}
@@ -50,7 +50,7 @@ bool __virt_addr_valid(unsigned long x)
if (unlikely(x > y)) {
x = y + phys_base;
- if (y >= KERNEL_IMAGE_SIZE)
+ if (y >= KERNEL_MAPPING_SIZE)
return false;
} else {
x = y + (__START_KERNEL_map - PAGE_OFFSET);
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m
From: Daniel Vetter @ 2017-01-04 8:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: dri-devel, LKML, kbuild test robot, Ben Skeggs
In-Reply-To: <029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org>
On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
> CONFIG_DRM_NOUVEAU=y.
> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
> kconfig value as LEDS_CLASS.
>
> drivers/built-in.o: In function `nouveau_do_suspend':
> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
> drivers/built-in.o: In function `nouveau_do_resume':
> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
> drivers/built-in.o: In function `nouveau_drm_unload':
> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
> drivers/built-in.o: In function `nouveau_drm_load':
> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>
> BTW, this line in Kbuild:
> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Cc: Martin Peres <martin.peres@free.fr>
> Cc: Ben Skeggs <bskeggs@redhat.com>
Thrown into drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/nouveau/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
> @@ -1,6 +1,7 @@
> config DRM_NOUVEAU
> tristate "Nouveau (NVIDIA) cards"
> depends on DRM && PCI
> + depends on LEDS_CLASS || LEDS_CLASS=n
> select FW_LOADER
> select DRM_KMS_HELPER
> select DRM_TTM
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v3 0/3] Determine kernel image mapping size at runtime for x86_64
From: Baoquan He @ 2017-01-04 8:37 UTC (permalink / raw)
To: tglx, hpa, mingo
Cc: linux-kernel, x86, keescook, yinghai, bp, thgarnie, kuleshovmail,
luto, mcgrof, anderson, dyoung, Baoquan He
Kernel behaviour is inconsistent between KASLR code is not compiled in
with CONFIG_RANDOMIZE_BASE disabled and user specifies "nokaslr" when
KASLR code compiled in with CONFIG_RANDOMIZE_BASE enabled. As long as
CONFIG_RANDOMIZE_BASE is enabled, kernel mapping size will be extended
up another 512M to 1G though "nokaslr" is specified explicitly. This is
buggy. CONFIG_RANDOMIZE_BASE should only decide if KASLR code need be
compiled in. If user specify "nokaslr", the kernel have to behave as no
KASLR code compiled in at all as expected.
The root cause of the inconsistency is the size of kernel image mapping
area is fixed at compiling time, and is changed from 512M to 1G as long
as CONFIG_RANDOMIZE_BASE is enabled.
So in this patchset, change to determine the size of kernel image mapping
area at runtime. Though KASLR code compiled in, if "nokaslr" specified,
still make kernel mapping size be 512M.
v1->v2:
Kbuild test threw build warning because of code bug.
v2->v3:
Boris pointed out patch log is not good for reviewing and understanding.
So split the old patch 2/2 into 2 parts and rewrite the patch log,
patch 2/3 is introducing the new constant KERNEL_MAPPING_SIZE which
differs from the old KERNEL_IMAGE_SIZE, patch 3/3 gets the kernel mapping
size at runtime.
Baoquan He (3):
x86/64: Make kernel text mapping always take one whole page table in
early boot code
x86/64: Introduce a new constant KERNEL_MAPPING_SIZE
x86/64/KASLR: Determine the kernel mapping size at run time
arch/x86/boot/compressed/kaslr.c | 20 +++++++++++++++-----
arch/x86/include/asm/kaslr.h | 1 +
arch/x86/include/asm/page_64_types.h | 20 ++++++++++++--------
arch/x86/include/asm/pgtable_64_types.h | 2 +-
arch/x86/kernel/head64.c | 11 ++++++-----
arch/x86/kernel/head_64.S | 16 +++++++++-------
arch/x86/mm/dump_pagetables.c | 3 ++-
arch/x86/mm/init_64.c | 2 +-
arch/x86/mm/physaddr.c | 6 +++---
9 files changed, 50 insertions(+), 31 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m
From: Daniel Vetter @ 2017-01-04 8:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: kbuild test robot, LKML, dri-devel, Ben Skeggs
In-Reply-To: <029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org>
On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
> CONFIG_DRM_NOUVEAU=y.
> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
> kconfig value as LEDS_CLASS.
>
> drivers/built-in.o: In function `nouveau_do_suspend':
> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
> drivers/built-in.o: In function `nouveau_do_resume':
> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
> drivers/built-in.o: In function `nouveau_drm_unload':
> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
> drivers/built-in.o: In function `nouveau_drm_load':
> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>
> BTW, this line in Kbuild:
> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Cc: Martin Peres <martin.peres@free.fr>
> Cc: Ben Skeggs <bskeggs@redhat.com>
Thrown into drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/nouveau/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
> @@ -1,6 +1,7 @@
> config DRM_NOUVEAU
> tristate "Nouveau (NVIDIA) cards"
> depends on DRM && PCI
> + depends on LEDS_CLASS || LEDS_CLASS=n
> select FW_LOADER
> select DRM_KMS_HELPER
> select DRM_TTM
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] fstests: Fix inconsistent xfs_io error report caused false alert
From: Qu Wenruo @ 2017-01-04 8:37 UTC (permalink / raw)
To: linux-btrfs, fstests
Test case like generic/304 and generic/158 can cause false alert due to
the error output change of xfs_io.
For error case, xfs_io mostly reports error like "dedupe: ERROR STRING"
while under certain case, it reports error like "XFS_IOC_FILE_EXTENT_SAME:
ERROR STRING".
Fix it by adding a new filter, _filter_dedupe_ioctl(), to filter out all
"XFS_IOC_FILE_EXTENT_SAME:" to "dedupe:"
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
---
common/filter | 8 ++++++++
tests/generic/158 | 9 ++++++---
tests/generic/158.out | 4 ++--
tests/generic/304 | 12 +++++++++---
tests/generic/304.out | 2 +-
5 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/common/filter b/common/filter
index 397b456..f9ad7f9 100644
--- a/common/filter
+++ b/common/filter
@@ -401,5 +401,13 @@ _filter_mknod()
sed -e "s/mknod: [\`']\(.*\)': File exists/mknod: \1: File exists/"
}
+# xfs_io has inconsistent error report prefix.
+# For some error it reports like "dedupe: STRING" while for some it
+# reports "XFS_IOC_FILE_EXTENT_SAME: STRING"
+# Use this filter to unify them to "dedupe:"
+_filter_dedupe_ioctl()
+{
+ sed -e "s/^XFS_IOC_FILE_EXTENT_SAME:/dedupe:/"
+}
# make sure this script returns success
/bin/true
diff --git a/tests/generic/158 b/tests/generic/158
index 086c522..88f3e47 100755
--- a/tests/generic/158
+++ b/tests/generic/158
@@ -98,7 +98,8 @@ echo "Try overlapping dedupe"
_dedupe_range $testdir1/file1 0 $testdir1/file1 1 $((blksz * 2))
echo "Try dedupe from past EOF"
-_dedupe_range $testdir1/file1 $(( (blks + 10) * blksz)) $testdir1/file1 0 $blksz
+_dedupe_range $testdir1/file1 $(( (blks + 10) * blksz)) $testdir1/file1 0 $blksz \
+ 2>&1 | _filter_dedupe_ioctl
echo "Try dedupe to past EOF, destination offset beyond EOF"
_dedupe_range $testdir1/file1 0 $testdir1/file1 $(( (blks + 10) * blksz)) \
@@ -109,10 +110,12 @@ _dedupe_range $testdir1/file1 0 $testdir1/file1 $(( (blks - 1) * blksz)) \
$((blksz * 2))
echo "Try to dedupe a dir"
-_dedupe_range $testdir1/dir1 0 $testdir1/file2 0 $blksz
+_dedupe_range $testdir1/dir1 0 $testdir1/file2 0 $blksz 2>&1 | \
+ _filter_dedupe_ioctl
echo "Try to dedupe a device"
-_dedupe_range $testdir1/dev1 0 $testdir1/file2 0 $blksz 2>&1 | _filter_enotty
+_dedupe_range $testdir1/dev1 0 $testdir1/file2 0 $blksz 2>&1 | \
+ _filter_enotty | _filter_dedupe_ioctl
echo "Try to dedupe to a dir"
_dedupe_range $testdir1/file1 0 $testdir1/dir1 0 $blksz 2>&1 | _filter_test_dir
diff --git a/tests/generic/158.out b/tests/generic/158.out
index 9b82ddf..3a9596f 100644
--- a/tests/generic/158.out
+++ b/tests/generic/158.out
@@ -14,9 +14,9 @@ dedupe: Invalid argument
Try dedupe to past EOF, destination offset behind EOF
dedupe: Invalid argument
Try to dedupe a dir
-XFS_IOC_FILE_EXTENT_SAME: Is a directory
+dedupe: Is a directory
Try to dedupe a device
-XFS_IOC_FILE_EXTENT_SAME: Invalid argument
+dedupe: Invalid argument
Try to dedupe to a dir
TEST_DIR/test-158/dir1: Is a directory
Try to dedupe to a device
diff --git a/tests/generic/304 b/tests/generic/304
index b7ee7b9..f8336fd 100755
--- a/tests/generic/304
+++ b/tests/generic/304
@@ -75,13 +75,19 @@ echo "Dedupe high offset to low offset"
_dedupe_range $testdir/file1 $bigoff_64k $testdir/file6 1048576 65535 >> $seqres.full
echo "Dedupe past source file EOF (should fail)"
-_dedupe_range $testdir/file2 524288 $testdir/file7 0 1048576 >> $seqres.full
+_dedupe_range $testdir/file2 524288 $testdir/file7 0 1048576 >> $seqres.full \
+ 2>$tmp.error
+cat $tmp.error | _filter_dedupe_ioctl
echo "Dedupe max size at nonzero offset (should fail)"
-_dedupe_range $testdir/file2 524288 $testdir/file8 0 $len >> $seqres.full
+_dedupe_range $testdir/file2 524288 $testdir/file8 0 $len >> $seqres.full \
+ 2>$tmp.error
+cat $tmp.error | _filter_dedupe_ioctl
echo "Dedupe with huge off/len (should fail)"
-_dedupe_range $testdir/file2 $bigoff_64k $testdir/file9 0 $bigoff_64k >> $seqres.full
+_dedupe_range $testdir/file2 $bigoff_64k $testdir/file9 0 $bigoff_64k \
+ >> $seqres.full 2>$tmp.error
+cat $tmp.error | _filter_dedupe_ioctl
echo "Check file creation"
_test_cycle_mount
diff --git a/tests/generic/304.out b/tests/generic/304.out
index 7b5ff0e..fbba6f3 100644
--- a/tests/generic/304.out
+++ b/tests/generic/304.out
@@ -14,7 +14,7 @@ dedupe: Invalid argument
Dedupe max size at nonzero offset (should fail)
dedupe: Invalid argument
Dedupe with huge off/len (should fail)
-XFS_IOC_FILE_EXTENT_SAME: Invalid argument
+dedupe: Invalid argument
Check file creation
file3
7ffffffffffffffe: 61 a
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/3] x86/64: Make kernel text mapping always take one whole page table in early boot code
From: Baoquan He @ 2017-01-04 8:37 UTC (permalink / raw)
To: tglx, hpa, mingo
Cc: linux-kernel, x86, keescook, yinghai, bp, thgarnie, kuleshovmail,
luto, mcgrof, anderson, dyoung, Baoquan He
In-Reply-To: <1483519053-23402-1-git-send-email-bhe@redhat.com>
In early boot code level2_kernel_pgt is used to map kernel text. And its
size varies with KERNEL_IMAGE_SIZE and fixed at compiling time. In fact
we can make it always take 512 entries of one whole page table, because
later function cleanup_highmap will clean up the unused entries. With the
help of this change kernel text mapping size can be decided at runtime
later, 512M if kaslr is disabled, 1G if kaslr is enabled.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
---
arch/x86/include/asm/page_64_types.h | 3 ++-
arch/x86/kernel/head_64.S | 15 ++++++++-------
arch/x86/mm/init_64.c | 2 +-
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 9215e05..62a20ea 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -56,8 +56,9 @@
* are fully set up. If kernel ASLR is configured, it can extend the
* kernel page table mapping, reducing the size of the modules area.
*/
+#define KERNEL_MAPPING_SIZE_EXT (1024 * 1024 * 1024)
#if defined(CONFIG_RANDOMIZE_BASE)
-#define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024)
+#define KERNEL_IMAGE_SIZE KERNEL_MAPPING_SIZE_EXT
#else
#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
#endif
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index b467b14..03bcb67 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -458,17 +458,18 @@ NEXT_PAGE(level3_kernel_pgt)
NEXT_PAGE(level2_kernel_pgt)
/*
- * 512 MB kernel mapping. We spend a full page on this pagetable
- * anyway.
+ * Kernel image size is limited to 512 MB. The kernel code+data+bss
+ * must not be bigger than that.
*
- * The kernel code+data+bss must not be bigger than that.
+ * We spend a full page on this pagetable anyway, so take the whole
+ * page here so that the kernel mapping size can be decided at runtime,
+ * 512M if no kaslr, 1G if kaslr enabled. Later cleanup_highmap will
+ * clean up those unused entries.
*
- * (NOTE: at +512MB starts the module area, see MODULES_VADDR.
- * If you want to increase this then increase MODULES_VADDR
- * too.)
+ * The module area starts after kernel mapping area.
*/
PMDS(0, __PAGE_KERNEL_LARGE_EXEC,
- KERNEL_IMAGE_SIZE/PMD_SIZE)
+ PTRS_PER_PMD)
NEXT_PAGE(level2_fixmap_pgt)
.fill 506,8,0
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index af85b68..45ef0ff 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -297,7 +297,7 @@ void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
void __init cleanup_highmap(void)
{
unsigned long vaddr = __START_KERNEL_map;
- unsigned long vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
+ unsigned long vaddr_end = __START_KERNEL_map + KERNEL_MAPPING_SIZE_EXT;
unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
pmd_t *pmd = level2_kernel_pgt;
--
2.5.5
^ permalink raw reply related
* Readjustment of proposal send email to : andreysaltanov-1srLxb0qcfWsTnJN9+BGXg@public.gmane.org with your fullnames, phone no., postal address for info.
From: ANDREY SALTANOV @ 2017-01-04 8:44 UTC (permalink / raw)
To: Recipients
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [ovmf baseline-only test] 68313: all pass
From: Platform Team regression test user @ 2017-01-04 8:44 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 68313 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68313/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ab50ab6ea159821d780be60759874dcf38835d1b
baseline version:
ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7
Last test of basis 68310 2017-01-03 15:17:10 Z 0 days
Testing same since 68313 2017-01-04 02:18:47 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jiaxin Wu <jiaxin.wu@intel.com>
Wu Jiaxin <jiaxin.wu@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
------------------------------------------------------------
commit ab50ab6ea159821d780be60759874dcf38835d1b
Author: Jiaxin Wu <jiaxin.wu@intel.com>
Date: Tue Jan 3 11:27:38 2017 +0800
NetworkPkg/Ip6Dxe: Fix the potential NULL pointer free
Ip6ConfigSetDnsServer may cause ASSERT if the invalid DNS
server address received. The issue is triggered by the NULL
pointer(Tmp) free.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
commit d52f9163debb523e06d49ed8a4627a0317bab92c
Author: Jiaxin Wu <jiaxin.wu@intel.com>
Date: Thu Dec 29 15:57:39 2016 +0800
MdeModulePkg/Ip4Dxe: Fix the potential NULL pointer free
Ip4Config2SetDnsServer may cause ASSERT if the invalid DNS
server address received. The issue is triggered by the NULL
pointer(Tmp) free.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging
From: Andrzej Hajda @ 2017-01-04 8:44 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: Russell King, dri-devel, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, linux-samsung-soc,
Krzysztof Kozlowski, Inki Dae, Hans Verkuil
In-Reply-To: <9652e8a9-1f5e-eadd-e588-b3051b0a8eb3@xs4all.nl>
On 03.01.2017 09:11, Hans Verkuil wrote:
> On 01/03/2017 09:00 AM, Andrzej Hajda wrote:
>> Is there a reason to split registration into two steps?
>> Wouldn't be better to integrate hpd_notifier_get into
>> cec_register_hpd_notifier.
> One problem is that hpd_notifier_get can fail, whereas cec_register_hpd_notifier can't.
> And I rather not have to register a CEC device only to unregister it again if the
> hpd_notifier_get would fail.
hpd_notifier_get can fail only due to lack of memory for about 150 bytes
so if it happens whole system will probably fail anyway :)
>
> Another reason is that this keeps the responsibility of the hpd_notifier life-time
> handling in the driver instead of hiding it in the CEC framework, which is IMHO
> unexpected.
Notifier is used only by CEC framework, so IMHO it would be desirable to
put CEC specific things into CEC framework.
Drivers duty is just to find notifier device.
Leaving it as is will just put little more burden on drivers, so this is
not big deal, do as you wish :)
Regards
Andrzej
>
> I think I want to keep this as-is, at least for now.
>
> Regards,
>
> Hans
>
>
>
>
^ permalink raw reply
* Re: [PATCH] drm/atomic: Add target_vblank support in atomic helpers.
From: Daniel Vetter @ 2017-01-04 8:43 UTC (permalink / raw)
To: Andrey Grodzovsky
Cc: Alexander.Deucher, daniel.vetter, Michel.Daenzer, dri-devel
In-Reply-To: <1483455998-26914-1-git-send-email-Andrey.Grodzovsky@amd.com>
On Tue, Jan 03, 2017 at 10:06:38AM -0500, Andrey Grodzovsky wrote:
> Allows usage of the new page_flip_target hook for
> drivers implementing the atomic path.
> Provides default atomic helper for the new hook.
>
> Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Please keep a per-patch changelog so that it's easier for everyone to
follow the evolution of this patch.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 146 ++++++++++++++++++++++++++++--------
> include/drm/drm_atomic_helper.h | 6 ++
> include/drm/drm_crtc.h | 3 +
> 3 files changed, 125 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 583f47f..5e76f90 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2733,6 +2733,59 @@ int drm_atomic_helper_resume(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
>
> +static int drm_atomic_helper_page_flip_create_state(
I'd just call this page_flip_common without the long namespace prefix
since it's static. And without the create_state name since this function
also does some basic checks.
> + struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event)
> +{
> + struct drm_plane *plane = crtc->primary;
> + struct drm_plane_state *plane_state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + crtc_state->event = event;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> +
> + ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> + if (ret != 0)
> + return ret;
> + drm_atomic_set_fb_for_plane(plane_state, fb);
> +
> + /* Make sure we don't accidentally do a full modeset. */
> + state->allow_modeset = false;
> + if (!crtc_state->active) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> + crtc->base.id);
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +static void drm_atomic_helper_page_flip_prepare_retry(
> + struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + drm_atomic_state_clear(state);
> + drm_atomic_legacy_backoff(state);
> +
> + /*
> + * Someone might have exchanged the framebuffer while we dropped locks
> + * in the backoff code. We need to fix up the fb refcount tracking the
> + * core does for us.
> + */
> + plane->old_fb = plane->fb;
There's a lot more places where we do this trick, please either refactor
them all, or none. Personally I'd go with none since the function call is
more verbose than the assignement, and you're hiding this rather important
comment behind a function name that doesn't say what games are being
played here.
> +}
> +
> /**
> * drm_atomic_helper_page_flip - execute a legacy page flip
> * @crtc: DRM crtc
> @@ -2756,8 +2809,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_atomic_state *state;
> - struct drm_plane_state *plane_state;
> - struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> @@ -2768,35 +2819,79 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> return -ENOMEM;
>
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> +
> retry:
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> + ret = drm_atomic_helper_page_flip_create_state(state, crtc, fb, event);
> + if (ret != 0)
> goto fail;
> - }
> - crtc_state->event = event;
>
> - plane_state = drm_atomic_get_plane_state(state, plane);
> - if (IS_ERR(plane_state)) {
> - ret = PTR_ERR(plane_state);
> - goto fail;
> - }
> + ret = drm_atomic_nonblocking_commit(state);
>
> - ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> +fail:
> + if (ret == -EDEADLK)
> + goto backoff;
> +
> + drm_atomic_state_put(state);
> + return ret;
> +
> +backoff:
> + drm_atomic_helper_page_flip_prepare_retry(state, plane);
> + goto retry;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_page_flip);
> +
> +/**
> + * drm_atomic_helper_page_flip - execute a legacy page flip
> + * @crtc: DRM crtc
> + * @fb: DRM framebuffer
> + * @event: optional DRM event to signal upon completion
> + * @flags: flip flags for non-vblank sync'ed updates
> + *
> + * Provides a default page flip on specific vblank implementation using
> + * the atomic driver interface.
> + *
> + * Note that for now so called async page flips (i.e. updates which are not
> + * synchronized to vblank) are not supported, since the atomic interfaces have
> + * no provisions for this yet.
> + *
> + * Returns:
> + * Returns 0 on success, negative errno numbers on failure.
Kerneldoc isn't updated, just verbatim copypaste. Please also linke these
2 functions. And if you have time, would be good to sprinkle links to the
vfunc hooks for each of these default helpers (they're unfortunately
missing ...), e.g. here &drm_crtc_funcs.page_flip_target.
And please build the docs per http://blog.ffwll.ch/2016/12/howto-docs.html
and make sure it all looks pretty.
> + */
> +int drm_atomic_helper_page_flip_on_target_vblank(
Please name this helper to match the vhook it's supposed to slot into,
i.e. drm_atomic_helper_page_flip_target.
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags,
> + uint32_t target)
> +{
> + struct drm_plane *plane = crtc->primary;
> + struct drm_atomic_state *state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> + return -EINVAL;
> +
> + state = drm_atomic_state_alloc(plane->dev);
> + if (!state)
> + return -ENOMEM;
> +
> + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> +
> +retry:
> + ret = drm_atomic_helper_page_flip_create_state(state, crtc, fb, event);
> if (ret != 0)
> goto fail;
> - drm_atomic_set_fb_for_plane(plane_state, fb);
>
> - /* Make sure we don't accidentally do a full modeset. */
> - state->allow_modeset = false;
> - if (!crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> - crtc->base.id);
> + crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> + if (WARN_ON(!crtc_state)) {
> ret = -EINVAL;
> goto fail;
> }
> + crtc_state->target_vblank = target;
>
> ret = drm_atomic_nonblocking_commit(state);
> +
> fail:
> if (ret == -EDEADLK)
> goto backoff;
> @@ -2805,19 +2900,10 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> return ret;
>
> backoff:
> - drm_atomic_state_clear(state);
> - drm_atomic_legacy_backoff(state);
> -
> - /*
> - * Someone might have exchanged the framebuffer while we dropped locks
> - * in the backoff code. We need to fix up the fb refcount tracking the
> - * core does for us.
> - */
> - plane->old_fb = plane->fb;
> -
> + drm_atomic_helper_page_flip_prepare_retry(state, plane);
> goto retry;
> }
> -EXPORT_SYMBOL(drm_atomic_helper_page_flip);
> +EXPORT_SYMBOL(drm_atomic_helper_page_flip_on_target_vblank);
>
> /**
> * drm_atomic_helper_connector_dpms() - connector dpms helper implementation
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 7ff92b0..e8cb6b7 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -124,6 +124,12 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> struct drm_pending_vblank_event *event,
> uint32_t flags);
> +int drm_atomic_helper_page_flip_on_target_vblank(
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags,
> + uint32_t target);
> int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
> int mode);
> struct drm_encoder *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 946672f..cc926dc 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -103,6 +103,7 @@ static inline uint64_t I642U64(int64_t val)
> * @ctm: Transformation matrix
> * @gamma_lut: Lookup table for converting pixel data after the
> * conversion matrix
> + * @target_vblank: Target vblank count to flip
> * @state: backpointer to global drm_atomic_state
> *
> * Note that the distinction between @enable and @active is rather subtile:
> @@ -156,6 +157,8 @@ struct drm_crtc_state {
> struct drm_property_blob *ctm;
> struct drm_property_blob *gamma_lut;
>
> + u32 target_vblank;
The in-line style is preferred for structures, since it allows to group
comments with each member. There's also still the question of how drivers
opt-in into target_vblank (only amdgpu, and then only in your private
branch supports it). I think that should be documented in the kernel-doc.
Thanks, Daniel
> +
> /**
> * @event:
> *
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Qemu-devel] [PATCH] serial: fix memory leak in serial exit
From: Li Qiang @ 2017-01-04 8:43 UTC (permalink / raw)
To: mst, pbonzini, qemu-devel; +Cc: Li Qiang
From: Li Qiang <liqiang6-s@360.cn>
The serial_exit_core function doesn't free some resources.
This can lead memory leak when hotplug and unplug. This
patch avoid this.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
---
hw/char/serial.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/hw/char/serial.c b/hw/char/serial.c
index ffbacd8..67b18ed 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -906,6 +906,16 @@ void serial_realize_core(SerialState *s, Error **errp)
void serial_exit_core(SerialState *s)
{
qemu_chr_fe_deinit(&s->chr);
+
+ timer_del(s->modem_status_poll);
+ timer_free(s->modem_status_poll);
+
+ timer_del(s->fifo_timeout_timer);
+ timer_free(s->fifo_timeout_timer);
+
+ fifo8_destroy(&s->recv_fifo);
+ fifo8_destroy(&s->xmit_fifo);
+
qemu_unregister_reset(serial_reset, s);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 1/4] ethdev: add firmware information get
From: Ferruh Yigit @ 2017-01-04 8:43 UTC (permalink / raw)
To: Wu, Jingjing, Yang, Qiming; +Cc: dev@dpdk.org, Horton, Remy, Thomas Monjalon
In-Reply-To: <9BB6961774997848B5B42BEC655768F810CC2AF1@SHSMSX103.ccr.corp.intel.com>
On 1/4/2017 7:48 AM, Wu, Jingjing wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yang, Qiming
>> Sent: Wednesday, January 4, 2017 11:33 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add firmware information get
>>
>> Yes, in my opinion it is. And I use this name already exist in the share code from
>> ND team.
>>
>> -----Original Message-----
>> From: Yigit, Ferruh
>> Sent: Tuesday, January 3, 2017 10:49 PM
>> To: Yang, Qiming <qiming.yang@intel.com>
>> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> Subject: Re: [PATCH v3 1/4] ethdev: add firmware information get
>>
>> On 1/3/2017 9:05 AM, Yang, Qiming wrote:
>>> Hi, Ferruh
>>> Please see the question below. In my opinion, etrack_id is just a name used to
>> define the ID of one NIC.
>>> In kernel version ethtool, it will print this ID in the line of firmware verison.
>>> I know what is etrack_id mean, but I really don't know why this named
>> etrack_id.
>>
>> Hi Qiming,
>>
>> I suggested the API based on fields you already used in your patch.
>>
>> So, this API is to get FW version, is etrack_id something that defines (part of)
>> firmware version?
>>
>> Thanks,
>> ferruh
>>
>>
> Different HW may have different version format, so it is better to use string.
>
> And I prefer the API definition in your v2 patch like
>
> rte_eth_dev_fwver_get(uint8_t port_id, char *fw_version, int fw_length);
The problem with this is the format and content of the string is not
defined, as you said different HW has different version format. This is
no problem if you will only print the string.
But this is a public API, if an application wants to call this API and
do something useful according the FW version information, it will need
to parse the string, and it will not able to parse it because format of
the string is not defined. By making API fill some defined variables,
app won't need to parse them, and API output won't be HW dependent.
Thanks,
ferruh
>
> Thanks
> Jingjing
>
^ permalink raw reply
* Re: Still OOM problems with 4.9er kernels
From: Gerhard Wiesinger @ 2017-01-04 8:40 UTC (permalink / raw)
To: Minchan Kim; +Cc: Michal Hocko, linux-kernel, linux-mm, Linus Torvalds
In-Reply-To: <20161223025505.GA30876@bbox>
On 23.12.2016 03:55, Minchan Kim wrote:
> On Fri, Dec 09, 2016 at 04:52:07PM +0100, Gerhard Wiesinger wrote:
>> On 09.12.2016 14:40, Michal Hocko wrote:
>>> On Fri 09-12-16 08:06:25, Gerhard Wiesinger wrote:
>>>> Hello,
>>>>
>>>> same with latest kernel rc, dnf still killed with OOM (but sometimes
>>>> better).
>>>>
>>>> ./update.sh: line 40: 1591 Killed ${EXE} update ${PARAMS}
>>>> (does dnf clean all;dnf update)
>>>> Linux database.intern 4.9.0-0.rc8.git2.1.fc26.x86_64 #1 SMP Wed Dec 7
>>>> 17:53:29 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> Updated bug report:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1314697
>>> Could you post your oom report please?
>> E.g. a new one with more than one included, first one after boot ...
>>
>> Just setup a low mem VM under KVM and it is easily triggerable.
>>
>> Still enough virtual memory available ...
>>
>> 4.9.0-0.rc8.git2.1.fc26.x86_64
>>
>> [ 624.862777] ksoftirqd/0: page allocation failure: order:0,
>> mode:0x2080020(GFP_ATOMIC)
>> [ 624.863319] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted
>> 4.9.0-0.rc8.git2.1.fc26.x86_64 #1
>> [ 624.863410] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.9.3
>> [ 624.863510] ffffaa62c007f958 ffffffff904774e3 ffffffff90c7dd98
>> 0000000000000000
>> [ 624.863923] ffffaa62c007f9e0 ffffffff9020e6ea 0208002000000246
>> ffffffff90c7dd98
>> [ 624.864019] ffffaa62c007f980 ffff96b900000010 ffffaa62c007f9f0
>> ffffaa62c007f9a0
>> [ 624.864998] Call Trace:
>> [ 624.865149] [<ffffffff904774e3>] dump_stack+0x86/0xc3
>> [ 624.865347] [<ffffffff9020e6ea>] warn_alloc+0x13a/0x170
>> [ 624.865432] [<ffffffff9020e9e2>] __alloc_pages_slowpath+0x252/0xbb0
>> [ 624.865563] [<ffffffff9020f74d>] __alloc_pages_nodemask+0x40d/0x4b0
>> [ 624.865675] [<ffffffff9020f983>] __alloc_page_frag+0x193/0x200
>> [ 624.866024] [<ffffffff907a1d7e>] __napi_alloc_skb+0x8e/0xf0
>> [ 624.866113] [<ffffffffc017777d>] page_to_skb.isra.28+0x5d/0x310
>> [virtio_net]
>> [ 624.866201] [<ffffffffc01794cb>] virtnet_receive+0x2db/0x9a0
>> [virtio_net]
>> [ 624.867378] [<ffffffffc0179bad>] virtnet_poll+0x1d/0x80 [virtio_net]
>> [ 624.867494] [<ffffffff907b501e>] net_rx_action+0x23e/0x470
>> [ 624.867612] [<ffffffff9091a8cd>] __do_softirq+0xcd/0x4b9
>> [ 624.867704] [<ffffffff900dd164>] ? smpboot_thread_fn+0x34/0x1f0
>> [ 624.867833] [<ffffffff900dd25d>] ? smpboot_thread_fn+0x12d/0x1f0
>> [ 624.867924] [<ffffffff900b7c95>] run_ksoftirqd+0x25/0x80
>> [ 624.868109] [<ffffffff900dd258>] smpboot_thread_fn+0x128/0x1f0
>> [ 624.868197] [<ffffffff900dd130>] ? sort_range+0x30/0x30
>> [ 624.868596] [<ffffffff900d82c2>] kthread+0x102/0x120
>> [ 624.868679] [<ffffffff909117a0>] ? wait_for_completion+0x110/0x140
>> [ 624.868768] [<ffffffff900d81c0>] ? kthread_park+0x60/0x60
>> [ 624.868850] [<ffffffff90917afa>] ret_from_fork+0x2a/0x40
>> [ 843.528656] httpd (2490) used greatest stack depth: 10304 bytes left
>> [ 878.077750] httpd (2976) used greatest stack depth: 10096 bytes left
>> [93918.861109] netstat (14579) used greatest stack depth: 9488 bytes left
>> [94050.874669] kworker/dying (6253) used greatest stack depth: 9008 bytes
>> left
>> [95895.765570] kworker/1:1H: page allocation failure: order:0,
>> mode:0x2280020(GFP_ATOMIC|__GFP_NOTRACK)
>> [95895.765819] CPU: 1 PID: 440 Comm: kworker/1:1H Not tainted
>> 4.9.0-0.rc8.git2.1.fc26.x86_64 #1
>> [95895.765911] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.9.3
>> [95895.766060] Workqueue: kblockd blk_mq_run_work_fn
>> [95895.766143] ffffaa62c0257628 ffffffff904774e3 ffffffff90c7dd98
>> 0000000000000000
>> [95895.766235] ffffaa62c02576b0 ffffffff9020e6ea 0228002000000046
>> ffffffff90c7dd98
>> [95895.766325] ffffaa62c0257650 ffff96b900000010 ffffaa62c02576c0
>> ffffaa62c0257670
>> [95895.766417] Call Trace:
>> [95895.766502] [<ffffffff904774e3>] dump_stack+0x86/0xc3
>> [95895.766596] [<ffffffff9020e6ea>] warn_alloc+0x13a/0x170
>> [95895.766681] [<ffffffff9020e9e2>] __alloc_pages_slowpath+0x252/0xbb0
>> [95895.766767] [<ffffffff9020f74d>] __alloc_pages_nodemask+0x40d/0x4b0
>> [95895.766866] [<ffffffff9026db51>] alloc_pages_current+0xa1/0x1f0
>> [95895.766971] [<ffffffff90916f17>] ? _raw_spin_unlock+0x27/0x40
>> [95895.767073] [<ffffffff90278956>] new_slab+0x316/0x7c0
>> [95895.767160] [<ffffffff9027ae8b>] ___slab_alloc+0x3fb/0x5c0
>> [95895.772611] [<ffffffff9010b042>] ? cpuacct_charge+0xf2/0x1f0
>> [95895.773406] [<ffffffffc005850d>] ? alloc_indirect.isra.11+0x1d/0x50
>> [virtio_ring]
>> [95895.774327] [<ffffffff901319d5>] ? rcu_read_lock_sched_held+0x45/0x80
>> [95895.775212] [<ffffffffc005850d>] ? alloc_indirect.isra.11+0x1d/0x50
>> [virtio_ring]
>> [95895.776155] [<ffffffff9027b0a1>] __slab_alloc+0x51/0x90
>> [95895.777090] [<ffffffff9027d141>] __kmalloc+0x251/0x320
>> [95895.781502] [<ffffffffc005850d>] ? alloc_indirect.isra.11+0x1d/0x50
>> [virtio_ring]
>> [95895.782309] [<ffffffffc005850d>] alloc_indirect.isra.11+0x1d/0x50
>> [virtio_ring]
>> [95895.783334] [<ffffffffc0059193>] virtqueue_add_sgs+0x1c3/0x4a0
>> [virtio_ring]
>> [95895.784059] [<ffffffff90068475>] ? kvm_sched_clock_read+0x25/0x40
>> [95895.784742] [<ffffffffc006665c>] __virtblk_add_req+0xbc/0x220
>> [virtio_blk]
>> [95895.785419] [<ffffffff901312fd>] ? debug_lockdep_rcu_enabled+0x1d/0x20
>> [95895.786086] [<ffffffffc0066935>] ? virtio_queue_rq+0x105/0x290
>> [virtio_blk]
>> [95895.786750] [<ffffffffc006695d>] virtio_queue_rq+0x12d/0x290
>> [virtio_blk]
>> [95895.787427] [<ffffffff9045015d>] __blk_mq_run_hw_queue+0x26d/0x3b0
>> [95895.788106] [<ffffffff904502e2>] blk_mq_run_work_fn+0x12/0x20
>> [95895.789065] [<ffffffff900d097e>] process_one_work+0x23e/0x6f0
>> [95895.789741] [<ffffffff900d08fa>] ? process_one_work+0x1ba/0x6f0
>> [95895.790444] [<ffffffff900d0e7e>] worker_thread+0x4e/0x490
>> [95895.791178] [<ffffffff900d0e30>] ? process_one_work+0x6f0/0x6f0
>> [95895.791911] [<ffffffff900d0e30>] ? process_one_work+0x6f0/0x6f0
>> [95895.792653] [<ffffffff90003eec>] ? do_syscall_64+0x6c/0x1f0
>> [95895.793397] [<ffffffff900d82c2>] kthread+0x102/0x120
>> [95895.794212] [<ffffffff90111775>] ? trace_hardirqs_on_caller+0xf5/0x1b0
>> [95895.794942] [<ffffffff900d81c0>] ? kthread_park+0x60/0x60
>> [95895.795689] [<ffffffff90917afa>] ret_from_fork+0x2a/0x40
>> [95895.796408] Mem-Info:
>> [95895.797110] active_anon:8800 inactive_anon:9030 isolated_anon:32
>> active_file:263 inactive_file:238 isolated_file:0
>> unevictable:0 dirty:0 writeback:330 unstable:0
>> slab_reclaimable:5241 slab_unreclaimable:9538
>> mapped:470 shmem:9 pagetables:2200 bounce:0
>> free:690 free_pcp:68 free_cma:0
>> [95895.801218] Node 0 active_anon:35200kB inactive_anon:36120kB
>> active_file:1052kB inactive_file:952kB unevictable:0kB isolated(anon):128kB
>> isolated(file):0kB mapped:1880kB dirty:0kB writeback:1320kB shmem:0kB
>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 36kB writeback_tmp:0kB
>> unstable:0kB pages_scanned:179 all_unreclaimable? no
>> [95895.803264] Node 0 DMA free:924kB min:172kB low:212kB high:252kB
>> active_anon:3544kB inactive_anon:3944kB active_file:84kB inactive_file:140kB
>> unevictable:0kB writepending:4kB present:15992kB managed:15908kB mlocked:0kB
>> slab_reclaimable:1728kB slab_unreclaimable:2964kB kernel_stack:84kB
>> pagetables:1396kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>> [95895.805936] lowmem_reserve[]: 0 117 117 117 117
>> [95895.806751] Node 0 DMA32 free:1836kB min:1296kB low:1620kB high:1944kB
>> active_anon:31636kB inactive_anon:32164kB active_file:968kB
>> inactive_file:804kB unevictable:0kB writepending:1288kB present:180080kB
>> managed:139012kB mlocked:0kB slab_reclaimable:19236kB
>> slab_unreclaimable:35188kB kernel_stack:1852kB pagetables:7404kB bounce:0kB
>> free_pcp:272kB local_pcp:156kB free_cma:0kB
>> [95895.809223] lowmem_reserve[]: 0 0 0 0 0
>> [95895.810071] Node 0 DMA: 36*4kB (H) 29*8kB (H) 22*16kB (H) 6*32kB (H)
>> 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 920kB
>> [95895.812089] Node 0 DMA32: 77*4kB (H) 71*8kB (H) 28*16kB (H) 8*32kB (H)
>> 4*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1836kB
>> [95895.813979] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0
>> hugepages_size=2048kB
>> [95895.813981] 1804 total pagecache pages
>> [95895.814931] 1289 pages in swap cache
>> [95895.815849] Swap cache stats: add 5288014, delete 5286725, find
>> 11568655/13881082
>> [95895.816792] Free swap = 1791816kB
>> [95895.817706] Total swap = 2064380kB
>> [95895.819222] 49018 pages RAM
>> [95895.820145] 0 pages HighMem/MovableOnly
>> [95895.821039] 10288 pages reserved
>> [95895.823325] 0 pages cma reserved
>> [95895.824244] 0 pages hwpoisoned
>> [95895.825237] SLUB: Unable to allocate memory on node -1,
>> gfp=0x2080020(GFP_ATOMIC)
>> [95895.826140] cache: kmalloc-256, object size: 256, buffer size: 256,
>> default order: 0, min order: 0
>> [95895.827034] node 0: slabs: 113, objs: 1808, free: 0
>> [97883.838418] httpd invoked oom-killer:
>> gfp_mask=0x24201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=0, order=0,
>> oom_score_adj=0
>> [97883.843507] httpd cpuset=/ mems_allowed=0
>> [97883.843601] CPU: 1 PID: 19043 Comm: httpd Not tainted
>> 4.9.0-0.rc8.git2.1.fc26.x86_64 #1
>> [97883.844628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.9.3
>> [97883.845839] ffffaa62c395f958 ffffffff904774e3 ffffaa62c395fb20
>> ffff96b98b8b3100
>> [97883.846970] ffffaa62c395f9e0 ffffffff902a8c41 0000000000000000
>> 0000000000000000
>> [97883.848388] ffffffff90ec6840 ffffaa62c395f990 ffffffff9011183d
>> ffffaa62c395f9b0
>> [97883.849945] Call Trace:
>> [97883.851366] [<ffffffff904774e3>] dump_stack+0x86/0xc3
>> [97883.852535] [<ffffffff902a8c41>] dump_header+0x7b/0x24f
>> [97883.853718] [<ffffffff9011183d>] ? trace_hardirqs_on+0xd/0x10
>> [97883.854857] [<ffffffff902085d3>] oom_kill_process+0x203/0x3e0
>> [97883.856192] [<ffffffff90208afb>] out_of_memory+0x13b/0x580
>> [97883.857334] [<ffffffff90208bea>] ? out_of_memory+0x22a/0x580
>> [97883.858590] [<ffffffff9020f31a>] __alloc_pages_slowpath+0xb8a/0xbb0
>> [97883.859706] [<ffffffff9020f74d>] __alloc_pages_nodemask+0x40d/0x4b0
>> [97883.860854] [<ffffffff90037de9>] ? sched_clock+0x9/0x10
>> [97883.862120] [<ffffffff9026db51>] alloc_pages_current+0xa1/0x1f0
>> [97883.863251] [<ffffffff90201d96>] __page_cache_alloc+0x146/0x190
>> [97883.864449] [<ffffffff9020366c>] ? pagecache_get_page+0x2c/0x300
>> [97883.865602] [<ffffffff90206055>] filemap_fault+0x345/0x790
>> [97883.866661] [<ffffffff90206238>] ? filemap_fault+0x528/0x790
>> [97883.867795] [<ffffffff903639d9>] ext4_filemap_fault+0x39/0x50
>> [97883.869289] [<ffffffff90241ca3>] __do_fault+0x83/0x1d0
>> [97883.870301] [<ffffffff90246642>] handle_mm_fault+0x11e2/0x17a0
>> [97883.871304] [<ffffffff902454ba>] ? handle_mm_fault+0x5a/0x17a0
>> [97883.872491] [<ffffffff9006de16>] __do_page_fault+0x266/0x520
>> [97883.873406] [<ffffffff9006e1a8>] trace_do_page_fault+0x58/0x2a0
>> [97883.874262] [<ffffffff90067f3a>] do_async_page_fault+0x1a/0xa0
>> [97883.875168] [<ffffffff90918e28>] async_page_fault+0x28/0x30
>> [97883.882611] Mem-Info:
>> [97883.883747] active_anon:2915 inactive_anon:3376 isolated_anon:0
>> active_file:3902 inactive_file:3639 isolated_file:0
>> unevictable:0 dirty:205 writeback:0 unstable:0
>> slab_reclaimable:9856 slab_unreclaimable:9682
>> mapped:3722 shmem:59 pagetables:2080 bounce:0
>> free:748 free_pcp:15 free_cma:0
>> [97883.890766] Node 0 active_anon:11660kB inactive_anon:13504kB
>> active_file:15608kB inactive_file:14556kB unevictable:0kB isolated(anon):0kB
>> isolated(file):0kB mapped:14888kB dirty:820kB writeback:0kB shmem:0kB
>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 236kB writeback_tmp:0kB
>> unstable:0kB pages_scanned:168352 all_unreclaimable? yes
>> [97883.893210] Node 0 DMA free:1468kB min:172kB low:212kB high:252kB
>> active_anon:1716kB inactive_anon:912kB active_file:2292kB
>> inactive_file:876kB unevictable:0kB writepending:24kB present:15992kB
>> managed:15908kB mlocked:0kB slab_reclaimable:4652kB
>> slab_unreclaimable:2852kB kernel_stack:76kB pagetables:496kB bounce:0kB
>> free_pcp:0kB local_pcp:0kB free_cma:0kB
>> [97883.898799] lowmem_reserve[]: 0 117 117 117 117
>> [97883.899735] Node 0 DMA32 free:1524kB min:1296kB low:1620kB high:1944kB
>> active_anon:9944kB inactive_anon:12572kB active_file:13316kB
>> inactive_file:13680kB unevictable:0kB writepending:768kB present:180080kB
>> managed:139012kB mlocked:0kB slab_reclaimable:34772kB
>> slab_unreclaimable:35876kB kernel_stack:1828kB pagetables:7824kB bounce:0kB
>> free_pcp:60kB local_pcp:52kB free_cma:0kB
>> [97883.903033] lowmem_reserve[]: 0 0 0 0 0
>> [97883.904371] Node 0 DMA: 36*4kB (H) 29*8kB (H) 22*16kB (H) 9*32kB (H)
>> 3*64kB (H) 2*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1464kB
>> [97883.906442] Node 0 DMA32: 13*4kB (H) 4*8kB (H) 13*16kB (H) 8*32kB (H)
>> 9*64kB (H) 1*128kB (H) 1*256kB (H) 0*512kB 0*1024kB 0*2048kB 0*4096kB =
>> 1508kB
> (H) mean highorder atomic reserved which was introduced since v4.4 and some
> patches to use up that reserved memory went to linux-next recently via mmotm
> tree.
> It doesn't land to 4.9 so it might help to test recent linux-next tree.
> It should include [1].
>
> [1] 04c8716f7b00, mm: try to exhaust highatomic reserve before the OOM
>
Ok, 4.10.0-0.rc2.git0.1.fc26.x86_64 is not stable (4.9.0-1.fc26.x86_64 was).
The VM stops working (e.g. not pingable) after around 8h (will be
restarted automatically), happened serveral times.
Had also further OOMs which I sent to Mincham.
Ciao,
Gerhard
^ permalink raw reply
* Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'
From: Segher Boessenkool @ 2017-01-04 8:40 UTC (permalink / raw)
To: Christophe LEROY; +Cc: benh, Christian Kujau, linuxppc-dev
In-Reply-To: <ca802791-9a7d-90b4-2025-852517225f14@c-s.fr>
On Wed, Jan 04, 2017 at 09:23:47AM +0100, Christophe LEROY wrote:
> >The way gcc implements the stack protector has some serious
> >incompatibilities with the way the Linux kernel uses r13, I wouldn't
> >even try until we sort that out...
>
> Yes indeed, it looks like recent versions of GCC don't use anymore the
> global __stack_chk_guard variable but a hard coded offset relative to r2
> or r13:
>
> On 32 bits, it uses -7008(r2)
> On 64 bits, it uses -7010(r13)
This is https://gcc.gnu.org/PR78875 . It should have been this way since
forever; if it really wasn't, it is unclear why not.
Either way, we (i.e. GCC) will add some compiler option to make this work
for the kernel. It will be part of 7 and we'll probably backport it to
6.4 and 5.5 .
For bootx_init.c, this probably should be compiled with -fno-stack-protector
just like all the other boot time stuff.
Segher
^ permalink raw reply
* Re: [PATCH v7 2/2] tpm: add securityfs support for TPM 2.0 firmware event log
From: Nayna @ 2017-01-04 8:38 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tpmdd-devel, peterhuewe, tpmdd, jgunthorpe, linux-security-module,
linux-kernel
In-Reply-To: <20170103133309.lt5k4c37rjq5vcbq@intel.com>
On 01/03/2017 07:03 PM, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 01:09:18PM +0530, Nayna wrote:
>>
>>
>> On 01/03/2017 03:42 AM, Jarkko Sakkinen wrote:
>>> On Sun, Dec 11, 2016 at 12:35:33AM -0500, Nayna Jain wrote:
>>>> Unlike the device driver support for TPM 1.2, the TPM 2.0 does
>>>> not support the securityfs pseudo files for displaying the
>>>> firmware event log.
>>>>
>>>> This patch enables support for providing the TPM 2.0 event log in
>>>> binary form. TPM 2.0 event log supports a crypto agile format that
>>>> records multiple digests, which is different from TPM 1.2. This
>>>> patch enables the tpm_bios_log_setup for TPM 2.0 and adds the
>>>> event log parser which understand the TPM 2.0 crypto agile format.
>>>>
>>>> Signed-off-by: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>
>>> There is something fundamentally wrong in this commit.
>>>
>>> You must not allow this feature unless CONFIG_OF is set. It is the only
>>> interface where the supply path of the event log is well defined on
>>> platforms that include a TPM 2.0 chip.
>>
>> As per current implementation, if ACPI with TPM 2.0 doesn't support event
>> log, tpm_read_log_acpi() is expected to return rc and tpm_bios_log_setup
>> will not create securityfs. This is inline with our design for TPM 1.2 event
>> log.
>
> At minimum you must have a check for TPM_CHIP_FLAG_TPM2 in the beginning
> of tpm_read_log_acpi. It is wrong to even try to open TCPA in this case.
Sure, will add this check and return -ENODEV if check passes.
Thanks & Regards,
- Nayna
>
> /Jarkko
>
^ permalink raw reply
* Re: [PATCH] mmc: dw_mmc: update clock after ctrl reset in runtime resume
From: Ziyuan @ 2017-01-04 8:39 UTC (permalink / raw)
To: Jaehoon Chung, Shawn Lin, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A
Cc: randy.li-TNX95d0MmH7DzftRWevZcw, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3b5329de-6aa9-4365-771b-11947989e910-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 01/04/2017 04:28 PM, Jaehoon Chung wrote:
> On 01/03/2017 03:59 PM, Shawn Lin wrote:
>> Hi Ziyuan,
>>
>> On 2017/1/3 14:46, Ziyuan Xu wrote:
>>> Immediately after reset, issue the command which sets
>>> update_clock_register_only bit, the card clock will restart.
>>>
>>> MMC_PM_KEEP_POWER is disabled for SD card and eMMC slots, so that they
>>> have no chance to invoke dw_mci_setup_bus for update clock behaviour.
>>> Let's consummate it.
>>>
>>> Fixes: e9ed883 ("mmc: dw_mmc: add runtime PM callback")
>>> Reported-by: Randy Li <randy.li-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> Signed-off-by: Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index b44306b..71715b4 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -3357,6 +3357,8 @@ int dw_mci_runtime_resume(struct device *dev)
>>> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>>> dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>>> dw_mci_setup_bus(slot, true);
>>> + } else {
>>> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK, 0);
>>> }
>>> }
>> Thanks for sending this, but I think the better fix we talked about
>> offlist may be...
>>
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -3324,7 +3324,7 @@ int dw_mci_runtime_resume(struct device *dev)
>> if (ret)
>> goto err;
>>
>> - if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) {
>> + if (!dw_mci_reset(host)) {
>> clk_disable_unprepare(host->ciu_clk);
>> ret = -ENODEV;
>> goto err;
>>
>>
>> otherwise there still some unhandled cases once the reset is failure.
> I think Shawn's suggestion is more better..After applied Shawn's suggestion, Is the problem disappeared?
> If then, could you resend the patch as Shawn's?
> I don't test yet with exynos..after testing, i will also share.
Fine. It a better approach. I will test it and share result ASAP.:-)
BR
Ziyuan Xu
>
> Best Regards,
> Jaehoon Chung
>
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH, REGRESSION] ubifs: fix unencrypted journal write
From: Peter Rosin @ 2017-01-04 8:38 UTC (permalink / raw)
To: Richard Weinberger, linux-kernel
Cc: Peter Rosin, Artem Bityutskiy, Adrian Hunter, David Gstir,
linux-mtd
Without this, I get the following on reboot:
UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad target node (type 1) length (8240)
UBIFS error (ubi1:0 pid 703): ubifs_load_znode: have to be in range of 48-4144
UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad indexing node at LEB 13:11080, error 5
magic 0x6101831
crc 0xb1cb246f
node_type 9 (indexing node)
group_type 0 (no node group)
sqnum 546
len 128
child_cnt 5
level 0
Branches:
0: LEB 14:72088 len 161 key (133, inode)
1: LEB 14:81120 len 160 key (134, inode)
2: LEB 20:26624 len 8240 key (134, data, 0)
3: LEB 14:81280 len 160 key (135, inode)
4: LEB 20:34864 len 8240 key (135, data, 0)
UBIFS warning (ubi1:0 pid 703): ubifs_ro_mode.part.0: switched to read-only mode, error -22
CPU: 0 PID: 703 Comm: mount Not tainted 4.9.0-next-20161213+ #1197
Hardware name: Atmel SAMA5
[<c010d2ac>] (unwind_backtrace) from [<c010b250>] (show_stack+0x10/0x14)
[<c010b250>] (show_stack) from [<c024df94>] (ubifs_jnl_update+0x2e8/0x614)
[<c024df94>] (ubifs_jnl_update) from [<c0254bf8>] (ubifs_mkdir+0x160/0x204)
[<c0254bf8>] (ubifs_mkdir) from [<c01a6030>] (vfs_mkdir+0xb0/0x104)
[<c01a6030>] (vfs_mkdir) from [<c0286070>] (ovl_create_real+0x118/0x248)
[<c0286070>] (ovl_create_real) from [<c0283ed4>] (ovl_fill_super+0x994/0xaf4)
[<c0283ed4>] (ovl_fill_super) from [<c019c394>] (mount_nodev+0x44/0x9c)
[<c019c394>] (mount_nodev) from [<c019c4ac>] (mount_fs+0x14/0xa4)
[<c019c4ac>] (mount_fs) from [<c01b5338>] (vfs_kern_mount+0x4c/0xd4)
[<c01b5338>] (vfs_kern_mount) from [<c01b6b80>] (do_mount+0x154/0xac8)
[<c01b6b80>] (do_mount) from [<c01b782c>] (SyS_mount+0x74/0x9c)
[<c01b782c>] (SyS_mount) from [<c0107f80>] (ret_fast_syscall+0x0/0x3c)
UBIFS error (ubi1:0 pid 703): ubifs_mkdir: cannot create directory, error -22
overlayfs: failed to create directory /mnt/ovl/work/work (errno: 22); mounting read-only
Fixes: 7799953b34d1 ("ubifs: Implement encrypt/decrypt for all IO")
Signed-off-by: Peter Rosin <peda@axentia.se>
---
fs/ubifs/journal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index a459211a1c21..a7932dcb2fc7 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -744,6 +744,7 @@ int ubifs_jnl_write_data(struct ubifs_info *c, const struct inode *inode,
} else {
data->compr_size = 0;
+ out_len = compr_len;
}
dlen = UBIFS_DATA_NODE_SZ + out_len;
--
2.1.4
^ permalink raw reply related
* Re: RFC: fb restore on drm master close
From: Stéphane Marchesin @ 2017-01-04 8:38 UTC (permalink / raw)
To: Daniel Vetter; +Cc: vcaputo, dri-devel@lists.freedesktop.org
In-Reply-To: <20170104083023.m6dqd3hh57twivvr@phenom.ffwll.local>
On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@pengaru.com wrote:
>> Hello list,
>>
>> I've been playing with an unaccelerated drm program[1] and have been
>> annoyed that whenever this program exits the fbcon isn't restored, with
>> the display left completely off.
>>
>> This seems to happen because Xorg is still running from a different VT.
>>
>> Upon further investigation, it seems like the fb restore only occurs on
>> "lastclose", which explains what I'm observing.
>>
>> Why don't we perform the fb restore whenever the current master is
>> closed to cover this case, since masters are the ones that can change
>> modes?
One case where it's useful not to do this is the handoff from a splash
screen to a display server.
Stéphane
>>
>> My github has a quick-n-dirty i915 implementation[2] which seems to fix
>> this without negative effects, though I haven't exhaustively tested to
>> see what breaks.
>>
>> This isn't a list I subscribe to so please CC me directly in any
>> replies, thanks everyone!
>
> The fbdev restore on lastclose was just a "oops, my X died and I have a
> black screen now" debug aid. Apps are supposed to restore fbdev themselves
> by switching back to text mode using KD_TEXT, which I think forces the
> modeset.
>
> In general though the fbdev vs. kms interaction is very ill-defined and
> mostly boils down to fbdev staying out of the way if anyone even might be
> using the native drm interfaces. We have the drm_fb_helper_is_bound check,
> but it's not used consistently either.
>
> Long story short, the answer to your question is "because no one yet
> thought this through", and I'm not clear at all what we should be doing
> here (if anything). I'm not sure whether your patch is the right approach,
> one issue it definitely has is that it only updates i915.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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.