Re: [PATCH] net/unix: drop obsolete fd-recursion limits

(2) call can fail spuriously with ETOOMANYREFS if a client > maliciously modifies the FD while inflight. > > Cc: Alban Crequy <alban.cre...@collabora.co.uk> > Cc: Simon McVittie <simon.mcvit...@collabora.co.uk> > Signed-off-by: David Herrmann <dh.herrm...@gmail

Re: [PATCH] net/unix: drop obsolete fd-recursion limits

th all of this in mind, lets drop the recursion limit. It has no > additional security value, anymore. On the contrary, it randomly > confuses message brokers that try to forward file-descriptors, since > any sendmsg(2) call can fail spuriously with ETOOMANYREFS if a client > maliciously modif

Re: [PATCH 2/2] x86/sysfb: fix lfb_size calculation

nn <dh.herrm...@gmail.com> Reviewed-by: Tom Gundersen <t...@jklm.no> > --- > arch/x86/kernel/sysfb_simplefb.c | 25 + > 1 file changed, 17 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kernel/sysfb_simplefb.c > b/arch/x86/kernel/sysfb_

Re: [PATCH 2/2] x86/sysfb: fix lfb_size calculation

e x86 simple-framebuffer setup code to use the correct size in the > non-VBE case. > > While at it, avoid variable abbreviations and rename 'len' to 'length', > and use the correct types matching the screen_info definition. > > Signed-off-by: David Herrmann Reviewed-by: Tom Gunder

Re: [PATCH 1/2] x86/sysfb: add support for 64bit EFI lfb_base

amebuffer devices. > > In particular, this means if VIDEO_CAPABILITY_64BIT_BASE is set, the > screen_info->ext_lfb_base field will contain the upper 32bit of the > actual lfb_base. Make sure the address is not 0 (i.e., unset), as well as > does not overflow the physical address type. > >

Re: [PATCH 1/2] x86/sysfb: add support for 64bit EFI lfb_base

ILITY_64BIT_BASE is set, the > screen_info->ext_lfb_base field will contain the upper 32bit of the > actual lfb_base. Make sure the address is not 0 (i.e., unset), as well as > does not overflow the physical address type. > > Signed-off-by: David Herrmann Reviewed-by: To

Re: [RFC v1 06/14] bus1: util - queue utility library

On Fri, Oct 28, 2016 at 3:58 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Fri, Oct 28, 2016 at 03:47:58PM +0200, Tom Gundersen wrote: >> On Fri, Oct 28, 2016 at 3:33 PM, Peter Zijlstra <pet...@infradead.org> wrote: >> > On Fri, Oct 28, 2016 at 01:33:2

Re: [RFC v1 06/14] bus1: util - queue utility library

On Fri, Oct 28, 2016 at 3:58 PM, Peter Zijlstra wrote: > On Fri, Oct 28, 2016 at 03:47:58PM +0200, Tom Gundersen wrote: >> On Fri, Oct 28, 2016 at 3:33 PM, Peter Zijlstra wrote: >> > On Fri, Oct 28, 2016 at 01:33:25PM +0200, Tom Gundersen wrote: > >> > And this, pr

Re: [RFC v1 06/14] bus1: util - queue utility library

On Fri, Oct 28, 2016 at 3:33 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Fri, Oct 28, 2016 at 01:33:25PM +0200, Tom Gundersen wrote: >> On Thu, Oct 27, 2016 at 6:43 PM, Peter Zijlstra <pet...@infradead.org> wrote: >> > On Wed, Oct 26, 2016 at 09:18:02

Re: [RFC v1 06/14] bus1: util - queue utility library

On Fri, Oct 28, 2016 at 3:33 PM, Peter Zijlstra wrote: > On Fri, Oct 28, 2016 at 01:33:25PM +0200, Tom Gundersen wrote: >> On Thu, Oct 27, 2016 at 6:43 PM, Peter Zijlstra wrote: >> > On Wed, Oct 26, 2016 at 09:18:02PM +0200, David Herrmann wrote: >> > >> >&

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

On Fri, Oct 28, 2016 at 3:11 PM, Richard Weinberger wrote: > On Wed, Oct 26, 2016 at 9:17 PM, David Herrmann wrote: >> Hi >> >> This proposal introduces bus1.ko, a kernel messaging bus. This is not a >> request >> for inclusion, yet. It is

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

On Fri, Oct 28, 2016 at 3:11 PM, Richard Weinberger wrote: > On Wed, Oct 26, 2016 at 9:17 PM, David Herrmann wrote: >> Hi >> >> This proposal introduces bus1.ko, a kernel messaging bus. This is not a >> request >> for inclusion, yet. It is rather an initial draft and a Request For Comments. >>

Re: [RFC v1 08/14] bus1: implement peer management context

On Fri, Oct 28, 2016 at 3:05 PM, Richard Weinberger wrote: > On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann wrote: >> + /* initialize constant fields */ >> + peer->id = atomic64_inc_return(_ids); >> + peer->flags = 0; >> +

Re: [RFC v1 08/14] bus1: implement peer management context

On Fri, Oct 28, 2016 at 3:05 PM, Richard Weinberger wrote: > On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann wrote: >> + /* initialize constant fields */ >> + peer->id = atomic64_inc_return(_ids); >> + peer->flags = 0; >> + peer->cred = get_cred(current_cred()); >> +

Re: [RFC v1 08/14] bus1: implement peer management context

On Fri, Oct 28, 2016 at 2:06 PM, Richard Weinberger wrote: > David, Tom, > > On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann wrote: >> +struct bus1_peer *bus1_peer_new(void) >> +{ >> + static atomic64_t peer_ids = ATOMIC64_INIT(0); >> +

Re: [RFC v1 08/14] bus1: implement peer management context

On Fri, Oct 28, 2016 at 2:06 PM, Richard Weinberger wrote: > David, Tom, > > On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann wrote: >> +struct bus1_peer *bus1_peer_new(void) >> +{ >> + static atomic64_t peer_ids = ATOMIC64_INIT(0); >> + const struct cred *cred = current_cred(); >> +

Re: [RFC v1 06/14] bus1: util - queue utility library

On Thu, Oct 27, 2016 at 6:43 PM, Peter Zijlstra wrote: > On Wed, Oct 26, 2016 at 09:18:02PM +0200, David Herrmann wrote: > >> A bus1 message queue is a FIFO, i.e., messages are linearly ordered by >> the time they were sent. Moreover, atomic delivery of messages to >>

Re: [RFC v1 06/14] bus1: util - queue utility library

On Thu, Oct 27, 2016 at 6:43 PM, Peter Zijlstra wrote: > On Wed, Oct 26, 2016 at 09:18:02PM +0200, David Herrmann wrote: > >> A bus1 message queue is a FIFO, i.e., messages are linearly ordered by >> the time they were sent. Moreover, atomic delivery of messages to >> multiple queues are

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 6:37 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Oct 27, 2016 at 8:25 AM, Tom Gundersen <t...@jklm.no> wrote: >> >> Could you elaborate on why you think syscalls would be more >> appropriate than ioctls? > >

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 6:37 PM, Linus Torvalds wrote: > On Thu, Oct 27, 2016 at 8:25 AM, Tom Gundersen wrote: >> >> Could you elaborate on why you think syscalls would be more >> appropriate than ioctls? > > ioctl's tend to be a horrid mess both for things like compat

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 11:11 AM, Arnd Bergmann <a...@arndb.de> wrote: > On Thursday, October 27, 2016 1:54:05 AM CEST Tom Gundersen wrote: >> On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski <l...@amacapital.net> wrote: >> > This may have been covered elsewher

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 11:11 AM, Arnd Bergmann wrote: > On Thursday, October 27, 2016 1:54:05 AM CEST Tom Gundersen wrote: >> On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski wrote: >> > This may have been covered elsewhere, but could this use syscalls instead? >> >

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski wrote: > This may have been covered elsewhere, but could this use syscalls instead? Yes, syscalls would work essentially the same. For now, we are using a cdev as it makes it a lot more convenient to develop and test as an

Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski wrote: > This may have been covered elsewhere, but could this use syscalls instead? Yes, syscalls would work essentially the same. For now, we are using a cdev as it makes it a lot more convenient to develop and test as an out-of-tree module, but

Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers

On Tue, Jul 7, 2015 at 1:23 AM, Luis R. Rodriguez wrote: > On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: >> On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez wrote: >> > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: >> >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry

Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers

On Tue, Jul 7, 2015 at 1:23 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: On Mon, Mar 30, 2015

Re: [!GIT PULL] kdbus for 4.2

On Fri, Jun 26, 2015 at 9:33 PM, Andy Lutomirski wrote: > What's a good distro on which to poke at a full running system? Fedora Rawhide is probably currently your best bet. > Fedora Rawhide seems to still build systemd with --disable-kdbus, > although I suppose that means that I could boot it

[PATCH][RFC] usbhid: enable autosuspend for internal devices

This policy used to be unconditionally applied by udev, but there is no reason to make userspace be involved in this and in the future udev will not be doing it by default. See: <https://github.com/systemd/systemd/pull/353>. Signed-off-by: Tom Gundersen Cc: Jiri Kosina Cc: Greg Kroah-H

Re: [!GIT PULL] kdbus for 4.2

On Fri, Jun 26, 2015 at 9:33 PM, Andy Lutomirski l...@amacapital.net wrote: What's a good distro on which to poke at a full running system? Fedora Rawhide is probably currently your best bet. Fedora Rawhide seems to still build systemd with --disable-kdbus, although I suppose that means that

[PATCH][RFC] usbhid: enable autosuspend for internal devices

This policy used to be unconditionally applied by udev, but there is no reason to make userspace be involved in this and in the future udev will not be doing it by default. See: https://github.com/systemd/systemd/pull/353. Signed-off-by: Tom Gundersen t...@jklm.no Cc: Jiri Kosina jkos...@suse.cz

Re: [GIT PULL] kdbus for 4.1-rc1

On 04/15/2015 10:22 PM, Andy Lutomirski wrote: > On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington wrote: >> That is, with dbus if I send a broadcast message, then send a unicast >> request to another client, then drop the connection causing the bus to >> broadcast that I've dropped; then the

Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 2:09 PM, Jiri Kosina wrote: > On Wed, 15 Apr 2015, Greg Kroah-Hartman wrote: > >> 'systemctl reboot' calls a bunch of other things to determine if you >> have local access to the machine, or permissions to reboot the machine >> (i.e. CAP_SYS_BOOT), and other things that

Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 2:09 PM, Jiri Kosina jkos...@suse.cz wrote: On Wed, 15 Apr 2015, Greg Kroah-Hartman wrote: 'systemctl reboot' calls a bunch of other things to determine if you have local access to the machine, or permissions to reboot the machine (i.e. CAP_SYS_BOOT), and other things

Re: [GIT PULL] kdbus for 4.1-rc1

On 04/15/2015 10:22 PM, Andy Lutomirski wrote: On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington h...@pobox.com wrote: That is, with dbus if I send a broadcast message, then send a unicast request to another client, then drop the connection causing the bus to broadcast that I've dropped; then

Re: [PATCH v4 00/14] Add kdbus implementation

On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski wrote: > On Mon, Mar 30, 2015 at 9:56 AM, David Herrmann wrote: >> Hi >> >> On Wed, Mar 25, 2015 at 7:12 PM, Andy Lutomirski wrote: >>> On Wed, Mar 25, 2015 at 10:29 AM, David Herrmann >>> wrote: >> [...] > I could be wrong about the lack

Re: [PATCH v4 00/14] Add kdbus implementation

On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Mar 30, 2015 at 9:56 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Wed, Mar 25, 2015 at 7:12 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Mar 25, 2015 at 10:29 AM, David Herrmann

[PATCH] net: nl80211 - pass name_assign_type to rdev_add_virtual_intf()

be renamed, so userspace needs to be able to reliably tell the difference. Similar functionality was introduced for the rtnetlink core in commit 5517750. Signed-off-by: Tom Gundersen Cc: Kalle Valo Cc: Brett Rudley Cc: Arend van Spriel Cc: Franky (Zhenhui) Lin Cc: Hante Meuleman Cc: Johannes

[PATCH] net: nl80211 - pass name_assign_type to rdev_add_virtual_intf()

be renamed, so userspace needs to be able to reliably tell the difference. Similar functionality was introduced for the rtnetlink core in commit 5517750. Signed-off-by: Tom Gundersen t...@jklm.no Cc: Kalle Valo kv...@qca.qualcomm.com Cc: Brett Rudley brud...@broadcom.com Cc: Arend van Spriel ar

Re: [PATCH 01/13] kdbus: add documentation

Hi Michael, On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages) wrote: > 2. Is the API to be invoked directly by applications or is intended to >be used only behind specific libraries? You seem to be saying that >the latter is the case (here, I'm referring to your comment above

Re: [PATCH 01/13] kdbus: add documentation

Hi Michael, On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: 2. Is the API to be invoked directly by applications or is intended to be used only behind specific libraries? You seem to be saying that the latter is the case (here, I'm referring to

Re: udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)

Hi Martin, On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares wrote: > The support for hwdb has finally landed in mainline pciutils. > > I have modified your patch to bring it closer to the rest of device > naming logic. Namely: Great! Thanks for merging this, and for working on it. > Aside of the

Re: udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)

Hi Martin, On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares m...@ucw.cz wrote: The support for hwdb has finally landed in mainline pciutils. I have modified your patch to bring it closer to the rest of device naming logic. Namely: Great! Thanks for merging this, and for working on it. Aside of

Re: [PATCH 00/12] Add kdbus implementation

On 10/30/2014 12:55 AM, Andy Lutomirski wrote:> It's worth noting that: > > - Proper credential passing could be added to UNIX sockets, and we > may want to do that anyway. Also, the current kdbus semantics seem to > be "spew lots of credentials and other miscellaneous > potentially-sensitive

Re: kdbus: add header file

On Thu, Oct 30, 2014 at 9:20 AM, Arnd Bergmann wrote: > I think in general, using enum is great, but for ioctl command numbers, > we probably want to have defines so the user space implementation can > use #ifdef to see if the kernel version that it is being built for > knows a particular

Re: [PATCH 00/12] Add kdbus implementation

Hi Eric, On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman wrote: > The userspace API breaks userspace in an unfixable way. > > Nacked-by: "Eric W. Biederman" > > Problem the first. > - Using global names for containers makes it impossible to create > unprivileged containers. I don't

Re: [PATCH 00/12] Add kdbus implementation

Hi Eric, On Thu, Oct 30, 2014 at 5:20 AM, Eric W. Biederman ebied...@xmission.com wrote: The userspace API breaks userspace in an unfixable way. Nacked-by: Eric W. Biederman ebied...@xmission.com Problem the first. - Using global names for containers makes it impossible to create

Re: kdbus: add header file

On Thu, Oct 30, 2014 at 9:20 AM, Arnd Bergmann a...@arndb.de wrote: I think in general, using enum is great, but for ioctl command numbers, we probably want to have defines so the user space implementation can use #ifdef to see if the kernel version that it is being built for knows a

Re: [PATCH 00/12] Add kdbus implementation

On 10/30/2014 12:55 AM, Andy Lutomirski wrote: It's worth noting that: - Proper credential passing could be added to UNIX sockets, and we may want to do that anyway. Also, the current kdbus semantics seem to be spew lots of credentials and other miscellaneous potentially-sensitive and

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov wrote: > 1) Why not to make the timeout configurable through config file? There > is already udev.conf you can put config option there. Thus people with > modprobe issues can easily "fix" the problem. And then decrease > default timeout back to 30

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: 1) Why not to make the timeout configurable through config file? There is already udev.conf you can put config option there. Thus people with modprobe issues can easily fix the problem. And then decrease default

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez wrote: > On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: >> Making kmod a special case is of course possible. However, as long as >> there is no fundamental reason why kmod should get this special >> treatment,

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: Making kmod a special case is of course possible. However, as long as there is no fundamental reason why kmod should get this special treatment, this just

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Tue, Sep 30, 2014 at 5:24 PM, Luis R. Rodriguez wrote: >> > commit e64fae5573e566ce4fd9b23c68ac8f3096603314 >> > Author: Kay Sievers >> > Date: Wed Jan 18 05:06:18 2012 +0100 >> > >> > udevd: kill hanging event processes after 30 seconds >> > >> > Some broken kernel drivers load

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Tue, Sep 30, 2014 at 5:24 PM, Luis R. Rodriguez mcg...@suse.com wrote: commit e64fae5573e566ce4fd9b23c68ac8f3096603314 Author: Kay Sievers kay.siev...@vrfy.org Date: Wed Jan 18 05:06:18 2012 +0100 udevd: kill hanging event processes after 30 seconds Some broken kernel

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Tue, Sep 30, 2014 at 4:27 AM, Luis R. Rodriguez wrote: > On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote: >> On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez >> wrote: >> > From: "Luis R. Rodriguez" >> > Systemd has a general t

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

On Tue, Sep 30, 2014 at 4:27 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote: On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Systemd has a general timeout

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

Hi Luis, Thanks for the patches and the detailed analysis. Feel free to add Acked-by: Tom Gundersen Minor comments on the commit message below. On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Some init systems may wish to

Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support

Hi Luis, Thanks for the patches and the detailed analysis. Feel free to add Acked-by: Tom Gundersen t...@jklm.no Minor comments on the commit message below. On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Some init

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez wrote: > On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote: >> How about simply introducing a new flag to finit_module() to indicate >> that the caller does not care about asynchronicity. We could then pass >> this fr

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez wrote: >>> More than two years >>> have gone by on growing design and assumptions on top of that original >>> commit. I'm not sure if *systemd folks* yet believe its was a design >>> regression? >> >> I don't think so. udev should not allow its

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: More than two years have gone by on growing design and assumptions on top of that original commit. I'm not sure if *systemd folks* yet believe its was a design regression? I don't think so. udev should not

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen t...@jklm.no wrote: How about simply introducing a new flag to finit_module() to indicate that the caller does not care about asynchronicity. We could then pass

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez wrote: > On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley > wrote: >> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote: >>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley >>> wrote: >>> > If we want to sort out some sync/async

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote: On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Tue, Sep 9, 2014 at 3:26 AM, Luis R. Rodriguez wrote: > On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo wrote: >> On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: >>> I'm not too convinced this is such a difficult problem to figure out. >>> We already have most of logic in place and the

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Tue, Sep 9, 2014 at 3:26 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo t...@kernel.org wrote: On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: I'm not too convinced this is such a difficult problem to figure out. We already have

Re: dell rbu driver and FW_LOADER_USER_HELPER

On Tue, Aug 26, 2014 at 7:14 PM, Luis R. Rodriguez wrote: > On Tue, Aug 26, 2014 at 07:09:46PM +0200, Luis R. Rodriguez wrote: >> When Christian tried removing the udev firmware loader >> it was detected that the Dell rbu driver still required >> use of FW_LOADER_USER_HELPER [0]. This driver

Re: dell rbu driver and FW_LOADER_USER_HELPER

On Tue, Aug 26, 2014 at 7:14 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Tue, Aug 26, 2014 at 07:09:46PM +0200, Luis R. Rodriguez wrote: When Christian tried removing the udev firmware loader it was detected that the Dell rbu driver still required use of FW_LOADER_USER_HELPER [0]. This

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Tue, Aug 12, 2014 at 10:29 AM, Dexuan Cui wrote: >> From: Tom Gundersen >> > Unluckily this logic doesn't work because the user-space daemons >> > like ifplugd, usually don't renew the DHCP immediately as long as they >> > receive a link-down message: t

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Tue, Aug 12, 2014 at 10:29 AM, Dexuan Cui de...@microsoft.com wrote: From: Tom Gundersen Unluckily this logic doesn't work because the user-space daemons like ifplugd, usually don't renew the DHCP immediately as long as they receive a link-down message: they usually wait for some seconds

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Mon, Aug 11, 2014 at 5:23 AM, Dexuan Cui wrote: >> -Original Message- >> From: Greg KH [mailto:gre...@linuxfoundation.org] >> > > > >> > > > IMO the most feasible and need-the-least-change solution may be: >> > > > the hyperv network VSC driver passes the event >> > > >

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Mon, Aug 11, 2014 at 5:23 AM, Dexuan Cui de...@microsoft.com wrote: -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] IMO the most feasible and need-the-least-change solution may be: the hyperv network VSC driver passes the event

Re: [PATCH v7 08/33] net: nl80211 - make rdev_add_virtual_intf take name_assign_type

Hi Johannes, On Mon, Jul 21, 2014 at 11:40 AM, Johannes Berg wrote: > On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote: >> Pass the value down and set it at the same place the name itself is set. > > Is this going to be applied as part of one bigger series? This patc

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Mon, Jul 21, 2014 at 12:21 PM, Yue Zhang (OSTC DEV) wrote: >> From: Tom Gundersen [mailto:t...@jklm.no] >> Sent: Monday, July 21, 2014 5:42 PM >> >> On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang wrote: >> > From: Yue Zhang >> > >> > This patch

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang wrote: > From: Yue Zhang > > This patch addresses the comment from Olaf Hering and Greg KH > for a previous commit 3a494e710367 ("hyperv: Add handler for > RNDIS_STATUS_NETWORK_CHANGE event") > > In previous solution, the driver calls "network restart"

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang yue...@microsoft.com wrote: From: Yue Zhang yue...@microsoft.com This patch addresses the comment from Olaf Hering and Greg KH for a previous commit 3a494e710367 (hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event) In previous solution, the

Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

On Mon, Jul 21, 2014 at 12:21 PM, Yue Zhang (OSTC DEV) yue...@microsoft.com wrote: From: Tom Gundersen [mailto:t...@jklm.no] Sent: Monday, July 21, 2014 5:42 PM On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang yue...@microsoft.com wrote: From: Yue Zhang yue...@microsoft.com This patch

Re: [PATCH v7 08/33] net: nl80211 - make rdev_add_virtual_intf take name_assign_type

Hi Johannes, On Mon, Jul 21, 2014 at 11:40 AM, Johannes Berg johan...@sipsolutions.net wrote: On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote: Pass the value down and set it at the same place the name itself is set. Is this going to be applied as part of one bigger series? This patch

Re: [PATCH net-next v9 4/9] net: set name_assign_type when setting names via ioctls

On Fri, Jul 18, 2014 at 1:20 AM, David Miller wrote: > From: Tom Gundersen > Date: Thu, 17 Jul 2014 10:06:05 +0200 > >> @@ -2787,10 +2788,13 @@ static int gsm_create_network(struct gsm_dlci *dlci, >> struct gsm_netconfig *nc) >> pr_debug("create network

Re: [PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

On Fri, Jul 18, 2014 at 1:19 AM, David Miller wrote: > From: Tom Gundersen > Date: Thu, 17 Jul 2014 10:06:04 +0200 > >> @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct >> genl_info *info) >> if (devname[nla_len(info->attrs[

Re: [PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

On Fri, Jul 18, 2014 at 1:19 AM, David Miller da...@davemloft.net wrote: From: Tom Gundersen t...@jklm.no Date: Thu, 17 Jul 2014 10:06:04 +0200 @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct genl_info *info) if (devname[nla_len(info-attrs

Re: [PATCH net-next v9 4/9] net: set name_assign_type when setting names via ioctls

On Fri, Jul 18, 2014 at 1:20 AM, David Miller da...@davemloft.net wrote: From: Tom Gundersen t...@jklm.no Date: Thu, 17 Jul 2014 10:06:05 +0200 @@ -2787,10 +2788,13 @@ static int gsm_create_network(struct gsm_dlci *dlci, struct gsm_netconfig *nc) pr_debug(create network interface

Re: [PATCH net-next v9 2/9] net: nl80211 - make rdev_add_virtual_intf take name_assign_type

On Thu, Jul 17, 2014 at 11:04 AM, Johannes Berg wrote: > On Thu, 2014-07-17 at 10:06 +0200, Tom Gundersen wrote: >> Pass the value down and set it at the same place the name itself is set. > > Huh? What's this? Can you explain why? Sure, sorry the context got lost. We want to ex

[PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

Signed-off-by: Tom Gundersen Acked-by: Alexander Aring Cc: Dmitry Eremin-Solenikov Cc: linux-zigbee-de...@lists.sourceforge.net --- include/net/wpan-phy.h | 4 +++- net/ieee802154/nl-phy.c| 5 - net/mac802154/ieee802154_dev.c | 7 --- 3 files changed, 11 insertions

[PATCH net-next v9 4/9] net: set name_assign_type when setting names via ioctls

When the user provides a name, set NET_NAME_USER, otherwise an enumerated name is used, so set NET_NAME_ENUM. Signed-off-by: Tom Gundersen --- drivers/net/tun.c | 9 ++--- drivers/tty/n_gsm.c | 10 +++--- net/atm/br2684.c | 5 +++-- net/bluetooth/bnep/core.c

[PATCH net-next v9 5/9] net: bond - make bond_create take name_assign_type

Signed-off-by: Tom Gundersen Cc: Jay Vosburgh Cc: Veaceslav Falico Cc: Andy Gospodarek --- drivers/net/bonding/bond_main.c | 7 --- drivers/net/bonding/bond_sysfs.c | 2 +- drivers/net/bonding/bonding.h| 2 +- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net

[PATCH net-next v9 9/9] net: ppp - set name assign type

and label it NET_NAME_USER. Signed-off-by: Tom Gundersen Cc: Paul Mackerras Cc: linux-...@vger.kernel.org --- drivers/net/ppp/ppp_generic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index c38ee90..6526057 100644 --- a/drivers/net

[PATCH net-next v9 6/9] net: isdn - set name assign type

Signed-off-by: Tom Gundersen Cc: Karsten Keil --- drivers/isdn/i4l/isdn_common.c | 4 ++-- drivers/isdn/i4l/isdn_net.c| 10 +- drivers/isdn/i4l/isdn_net.h| 4 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l

[PATCH net-next v9 7/9] net: vlan - set name assign type

When deriving the name from the real device, inherit the assign type, otherwise set PREDICTABLE as the name will be uniquely determined by the VLANID. Signed-off-by: Tom Gundersen Cc: Patrick McHardy --- net/8021q/vlan.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH net-next v9 2/9] net: nl80211 - make rdev_add_virtual_intf take name_assign_type

Pass the value down and set it at the same place the name itself is set. Signed-off-by: Tom Gundersen Cc: Johannes Berg Cc: John Linville --- drivers/net/wireless/ath/ath6kl/cfg80211.c| 6 -- drivers/net/wireless/ath/ath6kl/cfg80211.h| 1 + drivers/net/wireless

[PATCH net-next v9 8/9] net: openvswitch - set name assign type

Signed-off-by: Tom Gundersen Cc: Pravin Shelar Cc: d...@openvswitch.org --- v9: set NET_NAME_USER directly in internal_dev_create as requested by Pravin Shelar net/openvswitch/vport-internal_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/openvswitch/vport

[PATCH net-next v9 0/9] net: set the correct name_assign_type for more devices

currently a problem) the correct name assign type Patch 4:do the same for devices created via ioctls Patch 5-9: cover a few individual drivers More individual drivers will be converted in a follow-up series. Tom Gundersen (9): net: set name assign type for names assigned using a static st

[PATCH net-next v9 1/9] net: set name assign type for names assigned using a static string

This covers the trivial case: alloc_netdev(_, "bar", NET_NAME_PREDICTABLE, _); Signed-off-by: Tom Gundersen --- drivers/media/dvb-core/dvb_net.c | 2 +- drivers/misc/sgi-xp/xpnet.c | 2 +- drivers/net/caif/caif_virtio.c | 2 +- drivers/net/eql.c| 4 ++-- d

Re: [PATCH v8] net: set name assign type for names assigned using a static string

On Thu, Jul 17, 2014 at 9:26 AM, Veaceslav Falico wrote: > On Thu, Jul 17, 2014 at 09:17:07AM +0200, Tom Gundersen wrote: >> >> On Thu, Jul 17, 2014 at 8:56 AM, David Miller wrote: >>> >>> Tom, even if the patches are sort of independent, they logically >&

Re: [PATCH v8] net: set name assign type for names assigned using a static string

On Thu, Jul 17, 2014 at 8:56 AM, David Miller wrote: > Tom, even if the patches are sort of independent, they logically > belong together. > > So please number them, and provide an appropriate "[PATCH 0/N] ..." > cover letter. > > Please resubmit these patches with that done properly, thank you.

Re: [PATCH v8] net: set name assign type for names assigned using a static string

On Thu, Jul 17, 2014 at 8:56 AM, David Miller da...@davemloft.net wrote: Tom, even if the patches are sort of independent, they logically belong together. So please number them, and provide an appropriate [PATCH 0/N] ... cover letter. Please resubmit these patches with that done properly,

Re: [PATCH v8] net: set name assign type for names assigned using a static string

On Thu, Jul 17, 2014 at 9:26 AM, Veaceslav Falico vfal...@redhat.com wrote: On Thu, Jul 17, 2014 at 09:17:07AM +0200, Tom Gundersen wrote: On Thu, Jul 17, 2014 at 8:56 AM, David Miller da...@davemloft.net wrote: Tom, even if the patches are sort of independent, they logically belong together

[PATCH net-next v9 0/9] net: set the correct name_assign_type for more devices

a problem) the correct name assign type Patch 4:do the same for devices created via ioctls Patch 5-9: cover a few individual drivers More individual drivers will be converted in a follow-up series. Tom Gundersen (9): net: set name assign type for names assigned using a static string net

[PATCH net-next v9 1/9] net: set name assign type for names assigned using a static string

This covers the trivial case: alloc_netdev(_, bar, NET_NAME_PREDICTABLE, _); Signed-off-by: Tom Gundersen t...@jklm.no --- drivers/media/dvb-core/dvb_net.c | 2 +- drivers/misc/sgi-xp/xpnet.c | 2 +- drivers/net/caif/caif_virtio.c | 2 +- drivers/net/eql.c| 4

[PATCH net-next v9 2/9] net: nl80211 - make rdev_add_virtual_intf take name_assign_type

Pass the value down and set it at the same place the name itself is set. Signed-off-by: Tom Gundersen t...@jklm.no Cc: Johannes Berg johan...@sipsolutions.net Cc: John Linville linvi...@tuxdriver.com --- drivers/net/wireless/ath/ath6kl/cfg80211.c| 6 -- drivers/net/wireless/ath

  1   2   3   4   >