preparing for 4.5.2

preparing for 4.5.2

[Jan Beulich]

All,

with 4.5.2 being due in about 4 weeks please indicate to the respective
maintainers backports you see missing from but consider relevant for
the 4.5 stable branch. Please note that according to the outcome of a
recent discussion we're intending to do this release without any RC.

Thanks, Jan

Re: preparing for 4.5.2

[Ian Campbell]

Ian,

On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
> All,
> 
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent discussion we're intending to do this release without any RC.

Running through my list of ARM backports I found these two tools commits
which according to my notes are the only thing blocking the use of 64K
pages in Linux on Xen 4.5.

506f87b tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
7c0a96a tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()

Julien, is this still correct and is it still worth having for 4.5?

Re: preparing for 4.5.2

[Julien Grall]

On 25/09/15 13:17, Ian Campbell wrote:
> Ian,
> 
> On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
>> All,
>>
>> with 4.5.2 being due in about 4 weeks please indicate to the respective
>> maintainers backports you see missing from but consider relevant for
>> the 4.5 stable branch. Please note that according to the outcome of a
>> recent discussion we're intending to do this release without any RC.
> 
> Running through my list of ARM backports I found these two tools commits
> which according to my notes are the only thing blocking the use of 64K
> pages in Linux on Xen 4.5.
> 
> 506f87b tools/xenconsoled: Use XC_PAGE_SIZE rather than getpagesize()
> 7c0a96a tools/xenstored: Use XC_PAGE_SIZE rather than getpagesize()
> 
> Julien, is this still correct and is it still worth having for 4.5?

Yes, I was about to send an email to ask for backporting them.

Related to 64KB, there is another fix required in libxc:
31cf2ca tools/libxc: linux: Don't use getpagesize() when unmapping the
grants

Regards,

-- 
Julien Grall

Re: preparing for 4.5.2

[Ian Campbell]

Ian,

On Fri, 2015-09-25 at 05:16 -0600, Jan Beulich wrote:
> All,
> 
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent discussion we're intending to do this release without any RC.

I should have waited until I'd been right through my queue before hitting
send on the last mail. In my ARM queue I've also got these toolstack
patches:

201eac8 libxl: use correct command line for arm guests.
ed5c2c0 tools/libxc: arm: Check the index before accessing the bank

NB ed5c2c0 is supposed to be in staging-4.6 already too but I seem to have
failed to apply it when I said I had. I'll do that (but not 4.5) once the
current commit moratorium ends.

Ian.

Re: preparing for 4.5.2

[Konrad Rzeszutek Wilk]

On Fri, Sep 25, 2015 at 05:16:24AM -0600, Jan Beulich wrote:
> All,
> 
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent discussion we're intending to do this release without any RC.

 6a2f81459e1455d65a9a6f78dd2a0d0278619680

    xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 warnings.
    
folks on #xen (IRC) have asked for this to be backported.
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: preparing for 4.5.2

[Mark Pryor]

[-- Attachment #1.1: Type: text/plain, Size: 215 bytes --]

Hello,
request backport from 4.6 of:
2d70c9ce79d0201269b55ed6e906b25e83c7079boxenstored: link in the systemd system library
this is needed to build 4.5 from source on Ubuntu 15.04 (Vivid)

thanks,Mark PryorPryMar56

[-- Attachment #1.2: Type: text/html, Size: 1091 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: preparing for 4.5.2

[Mark Pryor]

[-- Attachment #1.1: Type: text/plain, Size: 989 bytes --]

On Fri, Sep 25, 2015 at 05:16:24AM -0600, Jan Beulich wrote:
> All,
> 
> with 4.5.2 being due in about 4 weeks please indicate to the respective
> maintainers backports you see missing from but consider relevant for
> the 4.5 stable branch. Please note that according to the outcome of a
> recent discussion we're intending to do this release without any RC.

 6a2f81459e1455d65a9a6f78dd2a0d0278619680

    xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 
warnings.
    
folks on #xen (IRC) have asked for this to be backported.
> 
> Thanks, Jan
> 
> 

for this patch to work on 4.5, each hunk header should shift 39 lines.
repaired patch attached 
 


     On Friday, September 25, 2015 8:37 AM, Mark Pryor <tlviewer@yahoo.com> wrote:
   

 Hello,
request backport from 4.6 of:
2d70c9ce79d0201269b55ed6e906b25e83c7079boxenstored: link in the systemd system library
this is needed to build 4.5 from source on Ubuntu 15.04 (Vivid)

thanks,Mark PryorPryMar56


   

[-- Attachment #1.2: Type: text/html, Size: 4288 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xen-flask-fixed.patch --]
[-- Type: text/x-patch, Size: 4323 bytes --]

commit 6a2f81459e1455d65a9a6f78dd2a0d0278619680
Author:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
AuthorDate: Wed Sep 16 15:57:27 2015 -0400
Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CommitDate: Tue Sep 22 12:09:03 2015 -0400

    xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 warnings.
    
    policydb.c: In function ‘user_read’:
    policydb.c:1443:26: error: ‘buf[2]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
             usrdatum->bounds = le32_to_cpu(buf[2]);
                              ^
    cc1: all warnings being treated as errors
    
    Which (as Andrew mentioned) is because GCC cannot assume
    that 'p->policyvers' has the same value between checks.
    
    We make it local, optimize the name to 'ver' and the warnings go away.
    We also update another call site with this modification to
    make it more inline with the rest of the functions.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index a1060b1..eebfe9c 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1219,6 +1219,7 @@ static int role_read(struct policydb *p, struct hashtab *h, void *fp)
     int rc;
     __le32 buf[3];
     u32 len;
+    u32 ver = p->policyvers;
 
     role = xzalloc(struct role_datum);
     if ( !role )
@@ -1227,7 +1228,7 @@ static int role_read(struct policydb *p, struct hashtab *h, void *fp)
         goto out;
     }
 
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
         rc = next_entry(buf, fp, sizeof(buf[0]) * 3);
     else
         rc = next_entry(buf, fp, sizeof(buf[0]) * 2);
@@ -1237,7 +1238,7 @@ static int role_read(struct policydb *p, struct hashtab *h, void *fp)
 
     len = le32_to_cpu(buf[0]);
     role->value = le32_to_cpu(buf[1]);
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
         role->bounds = le32_to_cpu(buf[2]);
 
     key = xmalloc_array(char, len + 1);
@@ -1289,6 +1290,7 @@ static int type_read(struct policydb *p, struct hashtab *h, void *fp)
     int rc;
     __le32 buf[4];
     u32 len;
+    u32 ver = p->policyvers;
 
     typdatum = xzalloc(struct type_datum);
     if ( !typdatum )
@@ -1297,7 +1299,7 @@ static int type_read(struct policydb *p, struct hashtab *h, void *fp)
         return rc;
     }
 
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
         rc = next_entry(buf, fp, sizeof(buf[0]) * 4);
     else
         rc = next_entry(buf, fp, sizeof(buf[0]) * 3);
@@ -1307,7 +1309,7 @@ static int type_read(struct policydb *p, struct hashtab *h, void *fp)
 
     len = le32_to_cpu(buf[0]);
     typdatum->value = le32_to_cpu(buf[1]);
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
     {
         u32 prop = le32_to_cpu(buf[2]);
 
@@ -1382,6 +1384,7 @@ static int user_read(struct policydb *p, struct hashtab *h, void *fp)
     int rc;
     __le32 buf[3];
     u32 len;
+    u32 ver = p->policyvers;
 
     usrdatum = xzalloc(struct user_datum);
     if ( !usrdatum )
@@ -1390,7 +1393,7 @@ static int user_read(struct policydb *p, struct hashtab *h, void *fp)
         goto out;
     }
 
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
         rc = next_entry(buf, fp, sizeof(buf[0]) * 3);
     else
         rc = next_entry(buf, fp, sizeof(buf[0]) * 2);
@@ -1400,7 +1403,7 @@ static int user_read(struct policydb *p, struct hashtab *h, void *fp)
 
     len = le32_to_cpu(buf[0]);
     usrdatum->value = le32_to_cpu(buf[1]);
-    if ( p->policyvers >= POLICYDB_VERSION_BOUNDARY )
+    if ( ver >= POLICYDB_VERSION_BOUNDARY )
         usrdatum->bounds = le32_to_cpu(buf[2]);
 
     key = xmalloc_array(char, len + 1);
@@ -1418,7 +1421,7 @@ static int user_read(struct policydb *p, struct hashtab *h, void *fp)
     if ( rc )
         goto bad;
 
-    if ( p->policyvers >= POLICYDB_VERSION_MLS )
+    if ( ver >= POLICYDB_VERSION_MLS )
     {
         rc = mls_read_range_helper(&usrdatum->range, fp);
         if ( rc )

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel