Bug#982579: Solution for loading firmware
Both patches applied and pushed out. In the future, could you please send the patches either as direct emails or as attachments or as pull requests? When you embed them in the body of the email I have to manually adjust them to get the commit log properly included. josh On Mon, Feb 22, 2021 at 4:24 PM maximilian attems wrote: > > please also add BananaPi M3 support. > > > From 216a0bda280e7b361c335f545156e86a059d9551 Mon Sep 17 00:00:00 2001 > From: maximilian attems > Date: Mon, 22 Feb 2021 22:18:36 +0100 > Subject: [PATCH 2/2] WHENCE: add missing symlink for BananaPi M3 > > Fixes (Debian bug #982579): > > [ 11.957171] brcmfmac mmc2:0001:1: firmware: failed to load > brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt (-2) > > [ 11.967106] firmware_class: See https://wiki.debian.org/Firmware for > information about missing firmware > > [ 11.977035] brcmfmac mmc2:0001:1: firmware: failed to load > brcm/brcmfmac43430-sdio.txt (-2) > > [ 12.994756] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): > > clkctl > 0x50 > > Reported-by: Bernhard > Signed-off-by: maximilian attems > --- > WHENCE | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/WHENCE b/WHENCE > index 11c0970..b569990 100644 > --- a/WHENCE > +++ b/WHENCE > @@ -2717,6 +2717,7 @@ File: "brcm/brcmfmac43430-sdio.AP6212.txt" > Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt -> > brcmfmac43430-sdio.AP6212.txt > Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt -> > brcmfmac43430-sdio.AP6212.txt > Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt -> > brcmfmac43430-sdio.AP6212.txt > +Link: brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt -> > brcmfmac43430-sdio.AP6212.txt > File: "brcm/brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt" > File: "brcm/brcmfmac43430-sdio.MUR1DX.txt" > File: "brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt" > -- > 2.30.0 >
Bug#770492: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks
On Sat, Jan 17, 2015 at 6:26 PM, Ben Hutchings b...@decadent.org.uk wrote: chown() and write() should clear all privilege attributes on a file - setuid, setgid, setcap and any other extended privilege attributes. However, any attributes beyond setuid and setgid are managed by the LSM and not directly by the filesystem, so they cannot be set along with the other attributes. Currently we call security_inode_killpriv() in notify_change(), but in case of a chown() this is too early - we have not called inode_change_ok() or made any filesystem-specific permission/sanity checks. Add a new function setattr_killpriv() which calls security_inode_killpriv() if necessary, and change the setattr() implementation to call this in each filesystem that supports xattrs. This assumes that extended privilege attributes are always stored in xattrs. Compile-tested only. XXX This is a silent change to the VFS API, but we should probably change something so OOT filesystems fail to compile if they aren't updated to call setattr_killpriv(). Reported-by: Ben Harris bj...@cam.ac.uk References: https://bugs.debian.org/770492 This seems to have stalled. I don't see it in linux-next or anywhere else I can find. The issue has a shiny CVE now, so it makes people that follow those nervous. Is there any further feedback or follow-up here? josh --- drivers/staging/lustre/lustre/llite/llite_lib.c | 4 fs/9p/vfs_inode.c | 4 fs/9p/vfs_inode_dotl.c | 4 fs/attr.c | 32 + fs/btrfs/inode.c| 4 fs/ceph/inode.c | 4 fs/cifs/inode.c | 11 - fs/ext2/inode.c | 4 fs/ext3/inode.c | 4 fs/ext4/inode.c | 4 fs/f2fs/file.c | 4 fs/fuse/dir.c | 15 +++- fs/fuse/file.c | 3 ++- fs/fuse/fuse_i.h| 2 +- fs/gfs2/inode.c | 3 +++ fs/hfs/inode.c | 4 fs/hfsplus/inode.c | 4 fs/jffs2/fs.c | 4 fs/jfs/file.c | 4 fs/kernfs/inode.c | 17 + fs/libfs.c | 3 +++ fs/nfs/inode.c | 11 +++-- fs/ocfs2/file.c | 6 - fs/reiserfs/inode.c | 4 fs/ubifs/file.c | 4 fs/xfs/xfs_acl.c| 3 ++- fs/xfs/xfs_file.c | 2 +- fs/xfs/xfs_ioctl.c | 2 +- fs/xfs/xfs_iops.c | 16 ++--- fs/xfs/xfs_iops.h | 10 ++-- include/linux/fs.h | 1 + mm/shmem.c | 4 32 files changed, 176 insertions(+), 25 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c b/drivers/staging/lustre/lustre/llite/llite_lib.c index a8bcc51..2a714b2 100644 --- a/drivers/staging/lustre/lustre/llite/llite_lib.c +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c @@ -1434,6 +1434,10 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr *attr, bool hsm_import) spin_unlock(lli-lli_lock); } + rc = setattr_killpriv(dentry, attr); + if (rc) + return rc; + /* We always do an MDS RPC, even if we're only changing the size; * only the MDS knows whether truncate() should fail with -ETXTBUSY */ diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index 296482f..735cbf84 100644 --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -1130,6 +1130,10 @@ static int v9fs_vfs_setattr(struct dentry *dentry, struct iattr *iattr) if (S_ISREG(dentry-d_inode-i_mode)) filemap_write_and_wait(dentry-d_inode-i_mapping); + retval = setattr_killpriv(dentry, iattr); + if (retval) + return retval; + retval = p9_client_wstat(fid, wstat); if (retval 0) return retval; diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c index 02b64f4..f3ca76d 100644 --- a/fs/9p/vfs_inode_dotl.c +++ b/fs/9p/vfs_inode_dotl.c @@ -583,6 +583,10 @@ int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct iattr *iattr) if (S_ISREG(inode-i_mode)) filemap_write_and_wait(inode-i_mapping); + retval =
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 11:26:18AM -0400, Steven Rostedt wrote: On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote: The *two* requirements (and they're really the same theme) I personally think we should have for this are - I think every single select for these things should come with a comment about what it is about and why the distro needs it (to show there was some thought involved and not just a blind took it from the distro config) What about expanding on Alan's idea. I'm guessing that 99% of the users build the kernel for the box that they are running. If this is the case, perhaps we can get the distros to add a: /usr/share/Linux/Kconfig And this Kconfig would have something like: bool Distro X config select A select B select C [...] Perhaps with a comment for each select. Or have the comments in the help section. Then have the kernel kbuild system check if this file exists and include it. Of course the kbuild system would need to verify that the selects exist, and perhaps warn if they do not. But the nice thing about this is that you would get the minconfig for the system you are running. When the system is updated to a new version, the minconfig would be updated too. The list of selects would not have to live in the kernel, nor would the kernel need to maintain the list for N+1 different distributions. Is there a reason you don't want distro maintainers to maintain these files in the upstream git tree? (You said the kernel need to maintain, but I would expect the distro maintainers to be doing that work.) I think it would actually be beneficial to maintain them upstream instead of in distro kernel packaging. You'd be able to track the history of changes with git. You would see for a given kernel version what options are set for each distro (e.g. F17 can support NEW_FOO_THING but F16 userspace can't so it doesn't select that). Perhaps most importantly, it provides a consolidated view of what options various distros are setting and allows the distro maintainers to easily do comparisons. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719154521.gc8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 12:08:08PM -0400, Steven Rostedt wrote: On Thu, 2012-07-19 at 11:45 -0400, Josh Boyer wrote: Of course the kbuild system would need to verify that the selects exist, and perhaps warn if they do not. But the nice thing about this is that you would get the minconfig for the system you are running. When the system is updated to a new version, the minconfig would be updated too. The list of selects would not have to live in the kernel, nor would the kernel need to maintain the list for N+1 different distributions. Is there a reason you don't want distro maintainers to maintain these files in the upstream git tree? (You said the kernel need to maintain, but I would expect the distro maintainers to be doing that work.) I think it would actually be beneficial to maintain them upstream instead of in distro kernel packaging. You'd be able to track the history of changes with git. You would see for a given kernel version what options are set for each distro (e.g. F17 can support NEW_FOO_THING but F16 userspace can't so it doesn't select that). Perhaps most importantly, it provides a consolidated view of what options various distros are setting and allows the distro maintainers to easily do comparisons. Then we'll have a list of options in each kernel: Fedora 16 Fedora 17 Fedora 18 [...] Debian x Debian x+1 Debian x+2 [...] Ubuntu y Ubuntu y+1 [...] Well, yes. I was thinking it would be more like: distro/Kconfig.fedora menuconfig FEDORA if FEDORA config FEDORA_16 select WHATEVER config FEDORA_17 ... distro/Kconfig.debian menuconfig DEBIAN if DEBIAN config DEBIAN_X ... etc. Not one giant distro file with a bunch of varying distros doing a bunch of selects. But in general, yes there would be options for each supported distro release. What about older kernels? Say you installed Fedora 18 with an older kernel that doesn't know what to select? Having the distro tell the kernel what it needs seems to me the easiest for the 99% case. How is the above not telling the kernel what it needs? I'm confused how the location of such a file makes it's functionality and usefulness differ... Quite possible I missed what you meant originally, but it sounds like we're talking about the same thing? Also, I'm not very convinced the 99% are going to be wanting to install shiny new versions of a distro with a kernel older than what the distro ships with. I could be very wrong, but it seems like in-general the whole premise of this RFC was geared towards using new kernels on distros. Also, if something isn't supported by the older kernel, it would warn the user about it. That way the user can be told that their older kernel won't work with this version of the distro. And there wont be as many surprises. If the user is told your init wont work with this kernel before they compile it, then they shouldn't complain if they decide to install this older kernel and their box doesn't boot. kconfig already spits out warnings for symbols being selected that don't exist. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719171918.gd8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote: Well, yes. I was thinking it would be more like: distro/Kconfig.fedora menuconfig FEDORA if FEDORA config FEDORA_16 select WHATEVER config FEDORA_17 Nope you need distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm boards)/Kconfig which for some distros is over 20 per release and the end user wouldn't have a cat in hells chance of knowing which to pick. I wasn't include arch-specific options in the minimal distro config stuff. That doesn't seem minimal to me. I was thinking more along the lines of distro X needs CGROUPS, SELINUX, HOTPLUG, DEVTMPFS, namespace stuff. Stuff that they need that is basically architecture independent that the distro userspace needs. Having the distro provide files that select architecture specific options and variations of that really doesn't seem any better than what most of them do already, which is just ship the whole damn config file in /boot (or some other location). For the end user case you need the distro to plonk the right file in the right place and be done with it, once they do that the rest is bikeshedding a ten line Makefile rule. If people want the distros to plonk some architecture+distro specific minimal config file down as part of the packaging, I guess that's a thing that could be done. I'd honestly wonder if maintaining X number of those in the packaging is something the distro maintainers would really like to do, but one can always hope. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719173800.ge8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:33:42PM -0400, Steven Rostedt wrote: On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote: What about older kernels? Say you installed Fedora 18 with an older kernel that doesn't know what to select? Having the distro tell the kernel what it needs seems to me the easiest for the 99% case. How is the above not telling the kernel what it needs? I'm confused how the location of such a file makes it's functionality and usefulness differ... Quite possible I missed what you meant originally, but it sounds like we're talking about the same thing? The point is, the user wont have to think What distro am I running? and what version am I running?. I don't even know what version of the disto I'm currently running (Debian testing). The point is, the current running distro supplies what is needed from the kernel in order to work properly. The user does not need to 'select' it. They would only have to select a 'add my distro min configs'. Distros aren't stationary things. I mean, some of them certainly aim for that goal, but userspace and kernels get upgraded all the time. So if this distro-Kconfig file is provided by some package _other_ than the kernel the distros are going to have a bit of a hassle keeping track of it. A developer working with a user could just say, select disto config without needing to know what distro the user has. What happens if someone does a yum update, and the kernel requirement changes slightly. The yum update should update this /usr/share/Linux/Kconfig. But it's still set at Fedora X. The kernel can not be updated for these slight changes. I'm not quite following what you mean in the yum update case, sorry. Also, I'm not very convinced the 99% are going to be wanting to install shiny new versions of a distro with a kernel older than what the distro ships with. I could be very wrong, but it seems like in-general the whole premise of this RFC was geared towards using new kernels on distros. There are times when the update breaks something. A user may backport to an older kernel where their Gizmo worked. I've done this to get webcams working. I know I'm not the 99%, but the rational for my operation was a 99% thing to do: Crap, I upgraded my kernel and now my webcam doesn't work. Oh well, download an older version and boot that one. Upgraded the kernel within the confines of that distro, right? So you go back to what was already installed and working. You don't go back arbitrarily far just to see what happens. I would think a reasonably crafted distro config would work in those scenarios. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719175649.gf8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 08:20:36PM +0200, Paul Bolle wrote: On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote: kconfig already spits out warnings for symbols being selected that don't exist. Does it? Since when does it do that? Or do you mean select in a more general way (not just meaning Kconfig's select statement)? I believe Alan was more correct than me when he said it was 'make oldconfig' that produced the warnings. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719182235.gg8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote: On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote: Distros aren't stationary things. Exactly my point. I mean, some of them certainly aim for that goal, but userspace and kernels get upgraded all the time. So if this distro-Kconfig file is provided by some package _other_ than the kernel the distros are going to have a bit of a hassle keeping track of it. How about a directory called /usr/share/Linux/Kconfig.d/ Then have anything installed that needs to work correctly put in its minimum (must have) requirement configs of the kernel. Say you are running Debian, and decide to try out systemd. If you set up your system to run that it would add a file called: /usr/share/Linux/Kconfig.d/systemd.conf or something, and this would select things like CGROUPS and the like. We could make the kernel build select all, or individual files in this directory. All for the 'make my distro work' or individual for a 'I want part of my distro to work' option. That sounds like a pretty good idea, aside from the fact that now your config is determined by 1) what is currently installed on your system and 2) people that don't maintain the kernel. 1 is obviously a great thing once you have a stable working set of packages you use daily, but wouldn't it kind of suck to have to rebuild the kernel just to install some new package? I mean... say you wanted to now use an NFS mount, but you didn't have nfs-utils previously installed. So you install it, and it plops the kconfig file in /usr/share but oops, you have to rebuild the kernel and reboot because that module isn't built. Of course I'm extrapolating possibly the worst usage case here, but it will still happen. 2... yeah. I don't really know if that is going to pan out, but I am ever hopeful. I'd be mostly concerned with people that are coding userspace applications using every whiz-bang kernel feature. Or not paying attention at all to the kernel after the initial file creation and the options going stale (don't follow renames, etc). Upgraded the kernel within the confines of that distro, right? So you go back to what was already installed and working. You don't go back arbitrarily far just to see what happens. I would think a reasonably crafted distro config would work in those scenarios. A reasonable one, but still not the minimum. The definition of minimum seems to be what we're disagreeing on. I'm approaching it from minimum for a default install of the distro release. OK, that and maybe a few common case usages (like NFS, CIFS, etc). You seem to be approaching it from literally bare minimum. One issue with Linus's proposal is that he's asking us to focus on the 99%. But the 99% of who? Because 99% of Linux users do not compile their own kernels, so he must be asking about the 99% of Linux users that compile their own kernels. This 99% does not just simply compile their kernels, but only want to compile the absolutely necessary stuff. That is, they want their kernels not to include anything they are not using. A reasonable config would probably need to include a lot that's not used. Perhaps. I thought getting it reasonable would benefit more people, even at the cost of some smaller bloat than bare minimum. I don't think either of us are really wrong, it's more a matter of who is really going to use this and why I guess. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719183645.gh8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 02:04:11PM -0700, da...@lang.hm wrote: On Thu, 19 Jul 2012, Josh Boyer wrote: On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote: On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote: Distros aren't stationary things. Exactly my point. I mean, some of them certainly aim for that goal, but userspace and kernels get upgraded all the time. So if this distro-Kconfig file is provided by some package _other_ than the kernel the distros are going to have a bit of a hassle keeping track of it. How about a directory called /usr/share/Linux/Kconfig.d/ Then have anything installed that needs to work correctly put in its minimum (must have) requirement configs of the kernel. Say you are running Debian, and decide to try out systemd. If you set up your system to run that it would add a file called: /usr/share/Linux/Kconfig.d/systemd.conf or something, and this would select things like CGROUPS and the like. We could make the kernel build select all, or individual files in this directory. All for the 'make my distro work' or individual for a 'I want part of my distro to work' option. That sounds like a pretty good idea, aside from the fact that now your config is determined by 1) what is currently installed on your system and 2) people that don't maintain the kernel. 1 is obviously a great thing once you have a stable working set of packages you use daily, but wouldn't it kind of suck to have to rebuild the kernel just to install some new package? I mean... say you wanted to now use an NFS mount, but you didn't have nfs-utils previously installed. So you install it, and it plops the kconfig file in /usr/share but oops, you have to rebuild the kernel and reboot because that module isn't built. Of course I'm extrapolating possibly the worst usage case here, but it will still happen. the alturnative to this is what? compile everything just in case you need it some time in the future? Why do people swing from one extreme to another so quickly? Surely there is some middle ground. we already have some tools (vmware) that check for the proper kernel config when they startup, and if the appropriate stuff isn't there they ask for the root password and compile the modules. 2... yeah. I don't really know if that is going to pan out, but I am ever hopeful. I'd be mostly concerned with people that are coding userspace applications using every whiz-bang kernel feature. Or not paying attention at all to the kernel after the initial file creation and the options going stale (don't follow renames, etc). it would be determined by the distro maintainers who maintain the kernel config for that distro. Erm... not in Steven's scheme. At least I don't think distro kernel maintainers are going to willingly crawl through every application package that might depend on a kernel feature being enabled and maintain those files across X number of packages. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719223519.gi8...@zod.bos.redhat.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 12:18 AM, Ben Hutchings b...@decadent.org.uk wrote: - distro/Kconfig: config DISTRO_REQUIREMENTS bool Pick minimal distribution requirements choice DISTRO prompt Distribution depends on DISTRO_REQUIREMENTS config FEDORA config OPENSUSE config UBUNTU ... endchoice and then depending on the DISTRO config, we'd include one of the distro-specific ones with lists of supported distro versions and then the random config settings for that version: You might also want to *un*select some options like CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2 that need to be set one way or the other depending on the version of udev. (I think it's possible to kluge this with the addition of a hidden negative config option.) How about stuff like NET and INET, that every distro will need and yet is configurable even without EXPERT? Yeah, I'm sure once distro configs are created we'll find quite a bit similarity in them. We could create Kconfig.distro that has all the common options selected and then have the per distro Kconfig files select that. Sure we'd need to watch Kconfig.distro (or Kconfig.min-distro) for changes, but I'd hope the distro maintainers would sign up to maintain these things upstream and be keeping an eye on it anyway. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+5pva4iovqybxr3nhd0m+kpnqqctvjrr+qexe632jlc5ns...@mail.gmail.com
Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote: On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones da...@redhat.com wrote: As long as you don't mind these being added after the fact, I suppose it would be workable. The reason I say that is sometimes, it even catches *us* by surprise. We recently found out our virtualisation guys started using sch_htb for example, and we inadvertantly broke it when we moved its module to a 'not always installed' kernel subpackage. (and before that, 9PFS..) People don't tell us anything, but somehow expect things to keep working. I think even a educated guess config file is better than what we have now. The *two* requirements (and they're really the same theme) I personally think we should have for this are - I think every single select for these things should come with a comment about what it is about and why the distro needs it (to show there was some thought involved and not just a blind took it from the distro config) - It should be about *minimal* settings. I'd rather have too few things and the occasional complaint about oh, it didn't work because it missed XYZ than have it grow to contain all the options just because somebody decided to just add random things until things worked. I'd agree that should be the goal. It seems like something worth at least trying to get to. Even if we don't wind up merging them into the kernel, it will at least lead to a better documented distro config for every one that tries it. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713222616.ga2...@zod.bos.redhat.com
Re: [Ksummit-2012-discuss] [ATTEND] Kernel summit - bwh
On Sat, Jun 16, 2012 at 12:44:18AM +0100, Ben Hutchings wrote: As a member of the Debian kernel team and maintainer of the 3.2.y stable series, I'm interested in discussing things like: - Ensuring that distributions can enable new features with minimal impact to those who don't use them - User documentation for new features (that aren't syscalls) - Process for backporting and re-testing bug fixes - Forwarding and tracking of bugs from distributions to upstream - Choosing kernel versions for distributions and 'longterm' stable branches - Early detection of bugs (static checking, test suites, more compiler diagnostics...) I'd very much like to discuss all of that. Also: - Maintenance of linux-firmware, and (if I haven't dealt with it by then) getting rid of the firmware directory This as well, though it might be small enough to do in a hallway track. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120616193233.gc28...@zod.bos.redhat.com
Re: Linux 3.2 in Debian 7.0
On Mon, Jan 30, 2012 at 3:04 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Jan 30, 2012 at 11:51:38AM -0800, Greg KH wrote: On Mon, Jan 30, 2012 at 03:46:29AM +, Ben Hutchings wrote: Greg, We've decided to go with Linux 3.2 for the next Debian stable release, so we'll be interested in a 3.2.y longterm series. I believe there was a volunteer from Ubuntu to look after that once you've had enough of it, but I seem to have lost the relevant mail. I will not be handing any stable/longterm maintance over to anyone who does not have a _lot_ of kernel community experience, so that seems to rule out just about all Ubuntu developers at this point in time from what I can tell. As I think this will be a Debian/Ubuntu thing only, I don't know if keeping the kernel.org version around for any length of time is really going to help much out here, do you? There is no connection between Debian and Ubuntu kernel packages, unlike many other packages that are co-maintained or copied between the distributions. So it is valuable to have a distinct upstream branch as the basis for our respective Linux kernel packages. A longterm 3.2.y branch might also be useful for Fedora 16, though the Fedora maintainers may prefer to carry on updating to newer mainline releases. Iffy on whether Fedora would use it. If anything, it would be more useful for Fedora 15 than Fedora 16. We'll likely rebase F16 to 3.3 as soon as 3.3.1 is released. I do appreciate the thoughts though. Once we get closer to a 3.3 rebase, we might revisit. josh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+5PVA4rC6Oa9-49K6LNSMqBz=y-kcjup_+wfh0pj0v7-rx...@mail.gmail.com
Bug#637740: [PATCH] uvcvideo: Fix crash when linking entities
On Wed, Sep 07, 2011 at 12:29:08AM +0200, Laurent Pinchart wrote: The uvc_mc_register_entity() function wrongfully selects the media_entity associated with a UVC entity when creating links. This results in access to uninitialized media_entity structures and can hit a BUG_ON statement in media_entity_create_link(). Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/uvc/uvc_entity.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) This patch should fix a v3.0 regression that results in a kernel crash as reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637740 and https://bugzilla.redhat.com/show_bug.cgi?id=735437. Test results will be welcome. I built a test kernel for Fedora with the patch and the submitter of the above bug has reported that the issue seems to be fixed. josh diff --git a/drivers/media/video/uvc/uvc_entity.c b/drivers/media/video/uvc/uvc_entity.c index 48fea37..29e2399 100644 --- a/drivers/media/video/uvc/uvc_entity.c +++ b/drivers/media/video/uvc/uvc_entity.c @@ -49,7 +49,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain *chain, if (remote == NULL) return -EINVAL; - source = (UVC_ENTITY_TYPE(remote) != UVC_TT_STREAMING) + source = (UVC_ENTITY_TYPE(remote) == UVC_TT_STREAMING) ? (remote-vdev ? remote-vdev-entity : NULL) : remote-subdev.entity; if (source == NULL) -- Regards, Laurent Pinchart -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907153240.gi10...@zod.bos.redhat.com
