On Tue, Sep 15, 2015 at 01:06:31PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > This is the start of the longterm review cycle for the 2.6.32.68 release.
> > All patches will be posted as a response to this one. If anyone has any
> > issue with these being applied, please let me know. If anyone is a
> > maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> > to the patch, please respond with it. If anyone thinks some important
> > patches are missing and should be added prior to the release, please
> > report them quickly with their respective mainline commit IDs.
> >
> > Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> > Anything received after that time might be too late. If someone
> > wants a bit more time for a deeper review, please let me know.
> >
> > NOTE: 2.6.32 is approaching end of support. There will probably be one
> > or maybe two other versions issued in the next 3-6 months, and that will
> > be all, at least for me. Adding to this the time it can take to validate
> > and deploy in some environments, it probably makes sense to start to
> > think about switching to another longterm branch. 3.2 and 3.4 are good
> > candidates for those seeking rock-solid versions. Longterm branches and
> > their projected EOLs are listed here :
> >
> > https://www.kernel.org/category/releases.html
> >
> > The whole patch series can be found in one patch at :
> > https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
> >
> > The shortlog and diffstat are appended below.
> [...]
>
> Patches 3 "crypto: testmgr - update LZO compression test vectors",
> 58 "dccp: fix auto-loading of dccp(_probe)",
> 60 "dccp: catch failed request_module call in dccp_probe init",
> 61 "dmaengine: fix missing cnt in ?: in dmatest" and
> 62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
> line in the commit mesage rather than the usual "commit xxx upstream."
Yes indeed, I cherry-picked them after the first build attempts when I
discovered build warnings. I'll add the line by hand.
> Patches 10 and 59 didn't reach me at all, though I can guess from its
> neighbours that 59 is cherry-picked from commit
> d984e6197ecd2babc1537f42dc1e676133005cda upstream.
Yep. Sorry for this, I'm attaching both of them to this e-mail, and
will add the upstream commit line to 59 as well.
Thanks,
Willy
>From 3f3fe288bb34818096135a93062ab588acbda269 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@xxxxxxx>
Date: Mon, 12 Dec 2011 15:13:50 +0100
Subject: udf: Treat symlink component of type 2 as /
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: Jan Kara <jack@xxxxxxx>
commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.
Currently, we ignore symlink component of type 2. But mkisofs and other OS'
seem to treat it as / so do the same for compatibility.
Reported-by: "Gábor S." <otnaccess@xxxxxxxxxxx>
Signed-off-by: Jan Kara <jack@xxxxxxx>
[bwh: Needed for the following fix]
Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
Signed-off-by: Willy Tarreau <w@xxxxxx>
---
fs/udf/symlink.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index e28a902..2d60484 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -43,10 +43,16 @@ static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
case 1:
- if (pc->lengthComponentIdent == 0) {
- p = to;
- *p++ = '/';
- }
+ /*
+ * Symlink points to some place which should be agreed
+ * upon between originator and receiver of the media. Ignore.
+ */
+ if (pc->lengthComponentIdent > 0)
+ break;
+ /* Fall through */
+ case 2:
+ p = to;
+ *p++ = '/';
break;
case 3:
memcpy(p, "../", 3);
--
1.7.12.2.21.g234cd45.dirty
>From 361fb30bc6abac898b3815bef9e9a56a95f46059 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 1 Dec 2011 14:45:49 -0500
Subject: dccp: Fix compile warning in probe code.
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix
auto-loading of dccp(_probe)") fixed a bug but created a new
compiler warning:
net/dccp/probe.c: In function â??dccpprobe_initâ??:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be â??trueâ??, suggest explicit middle operand [-Wparentheses]
try_then_request_module() is built for situations where the
"existence" test is some lookup function that returns a non-NULL
object on success, and with a reference count of some kind held.
Here we're looking for a success return of zero from the jprobe
registry.
Instead of fighting the way try_then_request_module() works, simply
open code what we want to happen in a local helper function.
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
(cherry picked from commit d984e6197ecd2babc1537f42dc1e676133005cda)
Signed-off-by: Willy Tarreau <w@xxxxxx>
---
net/dccp/probe.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 3ba43b8..89f25cb 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -151,6 +151,17 @@ static const struct file_operations dccpprobe_fops = {
.read = dccpprobe_read,
};
+static __init int setup_jprobe(void)
+{
+ int ret = register_jprobe(&dccp_send_probe);
+
+ if (ret) {
+ request_module("dccp");
+ ret = register_jprobe(&dccp_send_probe);
+ }
+ return ret;
+}
+
static __init int dccpprobe_init(void)
{
int ret = -ENOMEM;
@@ -164,8 +175,7 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
- "dccp");
+ ret = setup_jprobe();
if (ret)
goto err1;
--
1.7.12.2.21.g234cd45.dirty