On Wed, Jun 3, 2015 at 7:30 PM, Lucas De Marchi
wrote:
> On Mon, Jun 1, 2015 at 3:26 AM, Rusty Russell wrote:
>> Andreas Mohr writes:
>>> Hi,
>>>
>>> I just had a not so nice experience
>>> when finally upgrading to a new 4.1-rc5
>>> with CONFIG_MODULE_COMPRESS newly enabled -
>>> userspace bina
On Mon, Feb 2, 2015 at 8:34 PM, Maciej W. Rozycki wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>> > I thought that fixing the udev behavior would solve the problem. But
>> > it turned out that I was too naive. A bigger problem is that all
>> &g
On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai wrote:
> we've got a bug report about the mishandling of DVD/CDROM media eject
> button, and it seems indeed broken since some time ago. In short:
> when the eject button is pressed, the media is forcibly ejected no
> matter whether it's mounted or in
On Thu, Aug 21, 2014 at 2:30 PM, Sudeep Holla wrote:
> On 21/08/14 12:20, David Herrmann wrote:
>> On Thu, Aug 21, 2014 at 12:59 PM, Sudeep Holla
>> wrote:
>>>
>>> From: Sudeep Holla
>>>
>>> This patch creates a new class called "cpu" and assigns it to all the
>>> cpu devices. This helps in grou
On Thu, Jul 17, 2014 at 7:59 PM, Alex Elder wrote:
> This series rearranges the log code in such a way that the LOG_CONT
> and LOG_PREFIX log record flags can be eliminated entirely. The
> result should be considerably easier to understand than before. It
> builds on another recently-posted seri
On Mon, May 19, 2014 at 7:28 PM, Yoshihiro YUNOMAE
wrote:
> Add context information to the header of /dev/kmsg.
>
> Two printk messages connected with KERN_CONT can be divided in multiple lines
> by a different process context message. If the different context message seems
> like the 1st divided
On Tue, Apr 15, 2014 at 8:50 PM, Eric W. Biederman
wrote:
> Kay Sievers writes:
>
>> On Tue, Apr 15, 2014 at 7:48 PM, Li Zefan wrote:
>>> On 2014/4/15 5:44, Tejun Heo wrote:
>>>> cgroup users often need a way to determine when a cgroup's
>>>> su
On Tue, Apr 15, 2014 at 7:48 PM, Li Zefan wrote:
> On 2014/4/15 5:44, Tejun Heo wrote:
>> cgroup users often need a way to determine when a cgroup's
>> subhierarchy becomes empty so that it can be cleaned up. cgroup
>> currently provides release_agent for it; unfortunately, this mechanism
>> is r
On Sat, Mar 29, 2014 at 8:37 PM, David Miller wrote:
> From: Tom Gundersen
> Date: Sat, 29 Mar 2014 10:46:02 +0100
>
>> The issue I see with that is that there are several ways to generate
>> predictable names, and the user may want to chose between them, so
>> this is arguably policy that should
On Thu, Feb 27, 2014 at 2:31 PM, Peter Hurley wrote:
> On 02/27/2014 06:13 AM, Kay Sievers wrote:
>>
>> On Wed, Feb 26, 2014 at 3:40 PM, Peter Hurley
>> wrote:
>>>
>>> Enable a user-space process to discover the underlying tty device
>>> for a co
On Tue, Feb 25, 2014 at 10:38 AM, David Herrmann wrote:
> On Tue, Feb 25, 2014 at 8:51 AM, Hannes Reinecke wrote:
>> Positive?
>> I thought this was precisely the problem, ->device() changing the
>> index '0' into something non-zero.
>> The reports we had were that the line 'tty0' changed into '
On Wed, Feb 26, 2014 at 3:40 PM, Peter Hurley wrote:
> Enable a user-space process to discover the underlying tty device
> for a console, if one exists, and when the tty device is later
> created or destroyed.
>
> Add sysfs symlinks for registered consoles to their respective
> devices in [sys/cla
On Tue, Feb 25, 2014 at 6:34 PM, Dave Hansen wrote:
> On 02/24/2014 03:28 PM, Alexander Graf wrote:
>> Configuration of tunables and Linux virtual memory settings has traditionally
>> happened via sysctl. Thanks to that there are well established ways to make
>> sysctl configuration bits persisten
On Wed, Feb 26, 2014 at 12:16 AM, Alexander Graf wrote:
>
>
>>> Am 26.02.2014 um 01:19 schrieb Peter Zijlstra :
>>>
On Tue, Feb 25, 2014 at 12:15:28PM -0500, Johannes Weiner wrote:
On Tue, Feb 25, 2014 at 12:28:04AM +0100, Alexander Graf wrote:
Configuration of tunables and Linux vi
On Fri, Feb 21, 2014 at 3:56 PM, Josh Boyer wrote:
> On Fri, Feb 21, 2014 at 9:52 AM, Hannes Reinecke wrote:
>> On 02/21/2014 03:48 PM, Josh Boyer wrote:
>>> On Thu, Feb 20, 2014 at 6:52 PM, Greg Kroah-Hartman
>>> wrote:
3.13-stable review patch. If anyone has any objections, please let me
On Mon, Feb 17, 2014 at 2:19 AM, Kay Sievers wrote:
> On Mon, Feb 17, 2014 at 1:57 AM, Linus Torvalds
> wrote:
>> On Sun, Feb 16, 2014 at 4:50 PM, Kay Sievers wrote:
>>>
>>> That should avoid the overflow, yes. I expect it will not print the
>>> firs
On Mon, Feb 17, 2014 at 1:57 AM, Linus Torvalds
wrote:
> On Sun, Feb 16, 2014 at 4:50 PM, Kay Sievers wrote:
>>
>> That should avoid the overflow, yes. I expect it will not print the
>> first line with a prefix, which we probably should.?
>
> Well, it's not printi
On Mon, Feb 17, 2014 at 1:41 AM, Linus Torvalds
wrote:
> On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
> wrote:
> The third loop does *not* start again from the first line! It
> *continues* from where the second loop ended. Which is exactly why
> clearing "prev" is *wrong*. Because the *l
On Sun, Feb 16, 2014 at 9:47 PM, Greg Kroah-Hartman
wrote:
> On Sun, Feb 16, 2014 at 11:28:36AM -0800, Linus Torvalds wrote:
>> Adding Kay and Greg, since the original code is from commit
>> 7ff9554bb578 ("printk: convert byte-buffer to variable-length record
>> buffer") and all the "prev" flag tw
On Thu, Feb 6, 2014 at 5:29 PM, Greg Kroah-Hartman
wrote:
> On Thu, Feb 06, 2014 at 04:44:20PM +0100, Hannes Reinecke wrote:
>> On 02/06/2014 04:29 PM, Greg Kroah-Hartman wrote:
>> > On Thu, Feb 06, 2014 at 03:27:43PM +0100, Hannes Reinecke wrote:
>> >> The 'active' sysfs attribute should refer to
On Thu, Jan 16, 2014 at 10:29 AM, Jan Kaluža wrote:
> On 01/16/2014 12:23 AM, Tejun Heo wrote:
>> On Wed, Jan 15, 2014 at 06:21:43PM -0500, Eric Paris wrote:
>>>
>>> Reliably being able to audit what process requested an action is
>>> extremely useful. And I like the audit patch, as it is a coupl
On Fri, Jan 3, 2014 at 1:57 AM, Joe Perches wrote:
> (Adding Kay to cc's)
>
> Kay? any opinion on correctness?
Sounds fine by looking at it. Did not test anything though.
>> > --- a/kernel/printk/printk.c
>> > +++ b/kernel/printk/printk.c
>> > @@ -1604,7 +1604,10 @@ asmlinkage int vprintk_emit(
On Tue, Dec 24, 2013 at 3:50 AM, Yoshihiro YUNOMAE
wrote:
> (2013/12/20 20:29), Kay Sievers wrote:
>>
>> On Fri, Dec 20, 2013 at 10:41 AM, Yoshihiro YUNOMAE
>> wrote:
>>
>>> This patch set fixes message continuation breakage involved with
>>> struct
On Fri, Dec 20, 2013 at 10:41 AM, Yoshihiro YUNOMAE
wrote:
> Delete LOG_NEWLINE flag for structured printk.
> When structured printk is used, the next printk message is output in a new
> line
> from patch c313af145b9bc4fb8e8e0c83b8cfc10e1b894a50. However, in a following
> pseudo SCSI error test,
. This patch stores the dict information in structure
> cont
> first, then the information in cont is stored to log_buf.
>
> Signed-off-by: Yoshihiro YUNOMAE
> Cc: Kay Sievers
> Cc: Andrew Morton
> Cc: Joe Perches
> Cc: Tejun Heo
> Cc: Frederic Weisbecker
> Cc: l
On Fri, Dec 20, 2013 at 10:41 AM, Yoshihiro YUNOMAE
wrote:
> This patch set fixes message continuation breakage involved with structured
> printk. A SCSI driver may output two continuation error messages like
> scmd_printk("foo");
> printf("bar\n");
Which is the absolutely wrong thing to
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares wrote:
>> It does that per process doing that, and that's the problem for how
>> udev works/worked. The binary hwdb is on-disk and can be mmaped, and
>> there is no difference between initialization, first, or subsequent
>> queries.
>
> OK, point take
On Sun, Dec 15, 2013 at 10:18 AM, Martin Mares wrote:
> Hello Kay,
>
>> Libpci and its linear search through megabytes of text files for evey
>> new query is too inefficient, that we cannot afford to use it during
>> early bootup. It was the largest hit left in bootup profiling on
>> machines boot
On Sun, Dec 15, 2013 at 1:23 AM, Tom Gundersen wrote:
>> Also, did you consider the opposite, that is making hwdb call libpci
>> to resolve PCI IDs? What are the downsides?
>
> Well, part of the reason for introducing the hwdb was to avoid libpci for
> performance reasons (I added Kay in cc who ca
On Tue, Nov 12, 2013 at 3:08 AM, Kyungmin Park wrote:
> On Tue, Nov 12, 2013 at 10:19 AM, Kay Sievers wrote:
>> On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh
>> wrote:
>>> On Tue, 12 Nov 2013, Jingoo Han wrote:
>>>> On Tuesday, November 1
On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh
wrote:
> On Tue, 12 Nov 2013, Jingoo Han wrote:
>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>> > From: Kyungmin Park
>> >
>> > The most mobile phones have Ambient Light Sensors and it changes
>> > brightness accordin
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern wrote:
> Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> my kernel tree.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cb14ba75d57910cc4b62115dd5db7bd83c93684
Kay
--
To unsubscribe from this list:
On Mon, Sep 9, 2013 at 5:58 PM, Tom Gundersen wrote:
> Hi Konrad,
>
> The above commit (c70bda9 in mainline) doesn't appear to work for me.
> I.e., depmod does not create an entry in modules.devname and hence no
> device node is created on boot.
>
> If I understand correctly, you'd also need to cr
On Thu, Aug 29, 2013 at 4:13 PM, Jan Kaluza wrote:
> Add new SCM type called SCM_CGROUP to send "cgroup_path" in SCM.
> This is useful for journald (systemd logging daemon) to get additional context
> with each log line received using UNIX socket.
>
> Signed-off-by: Jan Kaluza
In many cases it's
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without an
On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>> CONFIG_FW_LOADER_USER_HELPER=y
> Do you need this? Unsetting this should help.
>
> """This option enables / disables the invocation of user-helper
> (e.g. udev)
On Mon, Jul 29, 2013 at 1:54 PM, Hidehiro Kawai
wrote:
> Also, I heard about the discussion
> at the kernel summit 2 years ago. According to the article of LWN,
> it seems that Linus objected your approach (i.e. adding random bit as
> message ID). Were there some agreements on this issue at the
On Wed, Jul 3, 2013 at 3:46 AM, Hidehiro Kawai
wrote:
> This patch series adds hash values of printk format strings into
> each line of /dev/kmsg outputs as follows:
>
> 6,154,325061,-,b7db707c@kernel/smp.c:554;Brought up 4 CPUs
/dev/kmsg is to a certain degree a kernel ABI. Having sourc
On Thu, Jul 25, 2013 at 5:03 PM, Dave Hansen wrote:
> On 07/25/2013 04:14 AM, KY Srinivasan wrote:
>> As promised, I have sent out the patches for (a) an implementation of an
>> in-kernel API
>> for onlining and a consumer for this API. While I don't know the exact
>> reason why the
>> user mod
On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers wrote:
> On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki wrote:
>
>> After a recent change present in 3.11-rc1 there is a driver, called
>> processor,
>> that can be bound to the CPU devices whose sysfs directories are l
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver
On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner wrote:
> On Sun, 30 Jun 2013, Lennart Poettering wrote:
>> On 29.06.2013 05:05, Tim Hockin wrote:
>> > But that's not my point. It seems pretty easy to make this cgroup
>> > management (in "native mode") a library that can have either a thin
>> > ve
On Sat, Jun 29, 2013 at 10:53 PM, Sami Kerola wrote:
> BTW having a way to measure effect of suspend/resume could lead to a
> way to fix time time distortion.
> Perhaps there is better alternative to fix user space programs.
> Unfortunately I do not have either knowledge, or imagination, to come
On Wed, May 8, 2013 at 6:26 PM, Takashi Iwai wrote:
> At Thu, 9 May 2013 00:07:17 +0800,
> Ming Lei wrote:
>> On Wed, May 8, 2013 at 2:56 PM, Takashi Iwai wrote:
>> > Hi,
>> >
>> > this is a series of patches for the issue we faced in the firmware
>> > loader code during debugging the problem wi
On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote:
>> FWIW, in the light of the original change, I've just removed the
>> /dev/rtc creation from the default udev rules now, so that thing will
>> be phased out in the future.
>
> Is that actually wanted? What happens to applications that use /dev/
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
wrote:
> So, my conclusion is nobody with a RTC looking for space savings, will
> disable CONFIG_RTC, which means we can safely rely on
> CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
> everyone who sets CONFIG_GENERIC_CMOS_UPDA
On Thu, Apr 25, 2013 at 9:11 AM, Alexander Holler wrote:
> Hmm, I thought RTC_SYSTOHC was there to update the used RTC clock with the
> time from NTP (and liked that).
That seems to have the nice self-explaining name CONFIG_GENERIC_CMOS_UPDATE. :)
> Therefor I don't understand why it is
> redun
On Wed, Apr 24, 2013 at 11:51 PM, Josh Boyer wrote:
>> In the daemon case, it's nice to be able to drop privileges after
>> setting up resources. The past was open /proc/kmsg with CAP_SYS_ADMIN,
>> then drop CAP_SYS_ADMIN and keep reading. Then later CAP_SYS_LOG was
>> introduced. So if a daemon
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote:
> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
> which enables some minor compile time optimization to avoid
> uncessary code in mostly the suspend/resume path could cause
> problems for userland.
>
>
On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote:
> On 04/24/2013 11:41 AM, Kay Sievers wrote:
>>
>> On Wed, Apr 24, 2013 at 8:32 PM, John Stultz
>> wrote:
>>>
>>> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
>>> which enabl
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote:
> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
> which enables some minor compile time optimization to avoid
> uncessary code in mostly the suspend/resume path could cause
> problems for userland.
>
>
On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote:
> On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote:
>> The dmesg_restrict sysctl currently covers the syslog method for access
>> dmesg, however /dev/kmsg isn't covered by the same protections. Most
>> people haven't noticed because util-linux dme
On Wed, Apr 24, 2013 at 6:30 PM, John Stultz wrote:
>> Until the above commits we always needed:
>>CONFIG_RTC_HCTOSYS=y
>>CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
>> to get the system time correctly initialized at bootup on x86.
> So... always needed to get system time correctly initialized? I'm
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz wrote:
> So summarizing the above, because as much as I'm aware, its always been
> redundant and unnecessary on x86. Thus being able at build time to mark it
> as unnecessary was attractive, since it reduced the code paths running at
> suspend/resume.
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers wrote:
> Also:
> $ cat /sys/class/rtc/rtc0/hctosys
> 0
> always carried "1", and this now breaks setups which expect an
> automatically created symlink /dev/rtc to the actual "system rtc".
We used to do t
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz wrote:
> On 04/23/2013 08:05 PM, Kay Sievers wrote:
>>
>> On Wed, Apr 24, 2013 at 4:43 AM, John Stultz
>> wrote:
>>>
>>> On 04/23/2013 06:34 PM, Kay Sievers wrote:
>>&
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz wrote:
> On 04/23/2013 06:34 PM, Kay Sievers wrote:
>>
>> Hey,
>>
>> what's the intention of:
>>e90c83f757fffdacec8b3c5eee5617dcc038338f ?
>>x86: Select HAS_PERSISTENT_CLOCK on x86
>>
>
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it impossible to sync the system time from the RTC on x86.
Wha
On Sat, Apr 6, 2013 at 7:58 PM, Greg KH wrote:
> On Sat, Apr 06, 2013 at 06:45:12PM +0100, Al Viro wrote:
>> On Sat, Apr 06, 2013 at 10:26:12AM -0700, Greg KH wrote:
>>
>> > Why not? "closed" systems, like Android and other embedded systems,
>> > have "assigned" uid and gid values that never chan
On Wed, Mar 20, 2013 at 10:11 PM, William Hubbs wrote:
> On Wed, Mar 20, 2013 at 02:03:20AM -0500, Rob Landley wrote:
>> On 03/19/2013 07:20:17 PM, William Hubbs wrote:
>> > On Tue, Mar 19, 2013 at 04:17:11PM -0700, H. Peter Anvin wrote:
>> > > On 03/19/2013 03:28 PM, William Hubbs wrote:
>> > > >
On Sun, Mar 17, 2013 at 3:36 PM, Myron Stowe wrote:
> On Sun, 2013-03-17 at 15:29 +0100, Kay Sievers wrote:
>> On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe wrote:
>> > On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
>> >> On Sun, Mar 17, 2013 at 2:38 PM
On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe wrote:
> On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
>> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
>> wrote:
>> > I'm assuming that the device only breaks because udevadm is dumping the
>> > full
On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
wrote:
> I'm assuming that the device only breaks because udevadm is dumping the
> full I/O port register space of the device and that if an actual driver
> was interacting with it through this interface that it would work. Who
> knows how many dev
On Sun, Mar 10, 2013 at 6:24 PM, Greg Kroah-Hartman
wrote:
> On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote:
>> On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman
>> wrote:
>> > On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote:
>> >> H
On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman
wrote:
> On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote:
>> Hey, guys.
>>
>> On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote:
>> > > Sorry for the delay, I'm at a conference all this
On Fri, Mar 8, 2013 at 12:31 AM, Greg Kroah-Hartman
wrote:
> On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote:
>> On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote:
>> > On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman
>> > wrote:
>> >
On Mon, Mar 4, 2013 at 8:51 AM, Eric W. Biederman wrote:
>
> Modify the request_module to prefix the file system type with "fs-"
> and add aliases to all of the filesystems that can be built as modules
> to match.
>
> A common practice is to build all of the kernel code and leave code
> that is no
On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman
wrote:
> On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote:
>> Kay tells me the most appropriate place to expose workqueues to
>> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
>> symlinked to /sys/bus/workqueue/devices
On Tue, Feb 12, 2013 at 12:15 AM, Josh Boyer wrote:
> Using /dev/pstore as a mount point for the pstore filesystem is slightly
> awkward. We don't normally mount filesystems in /dev/ and the /dev/pstore
> file isn't created automatically by anything. While this method will
> still work, we can c
On Mon, Feb 25, 2013 at 11:43 PM, Greg KH wrote:
> On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
>> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH wrote:
>>
>> > Hm, I thought we were frowning apon running binaries from udev rules
>> > these days, es
On Mon, Feb 25, 2013 at 11:12 PM, Greg KH wrote:
> Hm, I thought we were frowning apon running binaries from udev rules
> these days, especially ones that might have big consequences (like
> resizing a disk image) like this.
>
> Kay, am I right?
We removed most of them from the default setups, y
On Thu, Nov 29, 2012 at 11:46 PM, Joe Perches wrote:
> It's still a scheduling issue with Kay and Jan's patches.
> Does anyone have any idea if/when those patches are going in?
I was expecting that Jan rebases the patches incorporating
the latest fix. Jan?
It should not hold back anything else
On Thu, Nov 29, 2012 at 3:18 PM, Michael Kerrisk (man-pages)
wrote:
> So, just to be clear: you better not apply your patch; it might break
> something ;-).
Sounds good to me. :)
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Thu, Nov 29, 2012 at 2:37 PM, Michael Kerrisk (man-pages)
wrote:
> On Thu, Nov 29, 2012 at 2:28 PM, Kay Sievers wrote:
>> On Thu, Nov 29, 2012 at 2:18 PM, Michael Kerrisk (man-pages)
>> wrote:
>>> On Wed, Nov 28, 2012 at 6:51 PM, Kay Sievers wrote:
>&
On Thu, Nov 29, 2012 at 2:18 PM, Michael Kerrisk (man-pages)
wrote:
> On Wed, Nov 28, 2012 at 6:51 PM, Kay Sievers wrote:
>> Before:
>> syslog(SYSLOG_ACTION_SIZE_UNREAD, 0, 0) = 286965
>> syslog(SYSLOG_ACTION_READ_CLEAR, "<12>"..., 100) = 24000
>
On Wed, 2012-11-28 at 17:49 +0100, Kay Sievers wrote:
> On Wed, Nov 28, 2012 at 5:37 PM, Linus Torvalds
> wrote:
> > On Wed, Nov 28, 2012 at 8:22 AM, Kay Sievers wrote:
> >> On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk
> >> wrote:
> >>
>
On Wed, Nov 28, 2012 at 5:37 PM, Linus Torvalds
wrote:
> On Wed, Nov 28, 2012 at 8:22 AM, Kay Sievers wrote:
>> On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk
>> wrote:
>>
>>> On a 2.6.31 system, immediately after SYSLOG_ACTION_READ_CLEAR, a
>>> SYSLOG_
On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk wrote:
> On Thu, May 3, 2012 at 2:29 AM, Kay Sievers wrote:
>> From: Kay Sievers
> [...]
>> case SYSLOG_ACTION_SIZE_UNREAD:
>> - error = log_end - log_start;
>> +
On Thu, Nov 22, 2012 at 10:20 PM, Grant Likely
wrote:
> On Thu, Nov 22, 2012 at 7:17 PM, Kay Sievers wrote:
>> On Wed, Nov 21, 2012 at 3:52 PM, Greg Kroah-Hartman
>> wrote:
>>> If the devices don't show up under platform/ where are they going to be
>>>
On Thu, Nov 22, 2012 at 11:44 AM, Jan Schmidt wrote:
> I'm currently debugging something in btrfs in good old printk style,
> generating
> around 10MB/min. I'm seeing /proc/kmsg returning eof on a blocking read (and,
> side note, syslog-ng won't reopen it, effectively stopping logging kernel
> me
On Wed, Nov 21, 2012 at 3:52 PM, Greg Kroah-Hartman
wrote:
> On Wed, Nov 21, 2012 at 02:44:31PM +, Grant Likely wrote:
>> The "platform_bus" (note: not platform_bus_type) only exists as an empty
>> directory to put platform devices into. However, it really doesn't make
>> sense to segregate al
On Tue, Nov 20, 2012 at 9:42 PM, Kees Cook wrote:
> Since devtmpfs is writable, make the default noexec,nosuid as well. This
> protects from the case of a privileged process having an arbitrary file
> write flaw and an argumentless arbitrary execution (i.e. it would lack
> the ability to run "moun
On Sat, Nov 17, 2012 at 1:27 AM, Greg Kroah-Hartman
wrote:
> On Fri, Nov 16, 2012 at 04:20:16PM -0800, Kees Cook wrote:
>> Since devtmpfs is writable, make the default noexec nosuid as well. This
>> protects from the case of a privileged process having an arbitrary file
>> write flaw and an argume
On Thu, Nov 15, 2012 at 10:22 PM, "Jan H. Schönherr"
wrote:
> Am 15.11.2012 17:05, schrieb Kay Sievers:
>> This with all your patches applied:
>> [1.032804] input: ImExPS/2 Generic Explorer Mouse as
>> /devices/platform/i8042/serio1/input/input2
>>
On Wed, 2012-11-14 at 00:12 +0100, Jan H. Schönherr wrote:
> Hi Greg, hi Kay, and all other interested people.
>
> This series aims at cleaning up and fixing some bugs around printk().
> Patches 9 and 11 might require some discussion, see below.
This is how current git looks like:
[1.062953]
On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
>>> Jan,
>>> any updates, did you try something else?
>>> Or should we merge the first version for now?
>>
>> I'm working on it,
On Tue, Oct 23, 2012 at 8:36 AM, David Miller wrote:
> From: Doug Goldstein
> Date: Mon, 22 Oct 2012 00:53:57 -0500
>
>> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
>> applications that query network information via udev to identify vlans
>> instead of using strrchr().
On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
wrote:
> Am 08.10.2012 21:24, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
>>> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>>
>>>> Given that I
On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>> Given that I'm able to fix the racing case, would you be in favor of
>> this approach, or should we stick to the earlier version?
>
> I'm open
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
wrote:
> That said, there's clearly enough variation here that I think that for
> now I won't take the step to disable the udev part. I'll do the patch
> to support "direct filesystem firmware loading" using the udev default
> paths, and that hopeful
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote:
> As for the firmware path, maybe we should
> change that to be modified by userspace (much like /sbin/hotplug was) in
> a proc file so that distros can override the location if they need to.
If that's needed, a CONFIG_FIRMWARE_PATH= with the array
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds
wrote:
> On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>>
>>> Ok, like this?
>>
>> This looks good to me. Having udev do firmware loading and tieing it to
>> the driver model may have not been such a good idea so many years ago.
>> Doing it this
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH wrote:
>> It's the same in the current release, we still haven't wrapped our
>> head around how to fix it/work around it.
>
> Ick, as this is breaking people's previously-working machines, shouldn't
> this be resolved quickly?
Nothing really "breaks", It's
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote:
> Mauro, what version of udev are you using that is still showing this
> issue?
>
> Kay, didn't you resolve this already? If not, what was the reason why?
It's the same in the current release, we still haven't wrapped our
head around how to fix it
On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
wrote:
> Am 28.09.2012 16:34, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
>> The current behaviour has the advantage, that non-cont users will not
>> race against a cont user (whi
On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
wrote:
>> If really, really everything passes through vprintk_emit()
>> then we could keep all info about the previous message
>> there and definitely decide whether the current message continues
>> the previous one.
>>
>> Then, we wouldn't need
On Thu, Sep 27, 2012 at 5:46 PM, "Jan H. Schönherr"
wrote:
> Am 27.09.2012 15:39, schrieb Kay Sievers:
>> It is a flag that we have not been able to merge a continuation line
>> in the buffer, because we had a race with another thread, or the
>> console lock w
On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
wrote:
> Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
>> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>>> Against v3.6-rc7, only lightly tested.
>>
>> Well, against linux-next and highly tested would be best. It's a bit
On Fri, Sep 14, 2012 at 9:29 PM, Tejun Heo wrote:
> On Fri, Sep 14, 2012 at 09:58:30AM -0400, Vivek Goyal wrote:
>> I am little concerned about above and wondering how systemd and libvirt
>> will interact and behave out of the box.
>>
>> Currently systemd does not create its own hierarchy under bl
On Thu, Aug 23, 2012 at 5:16 PM, Ming Lei wrote:
> On Tue, Aug 21, 2012 at 1:34 PM, Ming Lei wrote:
>> I found that udev 182 doesn't response for the request_firmware in
>> module_probe path until 30sec later after the 'ADD' event of firmware
>> device, but no such problem in udev175, sounds lik
1 - 100 of 428 matches
Mail list logo
