1. 09 1月, 2012 23 次提交
  2. 05 1月, 2012 7 次提交
  3. 04 1月, 2012 10 次提交
    • L
      Revert "rtc: Expire alarms after the time is set." · f423fc62
      Linus Torvalds 提交于
      This reverts commit 93b2ec01.
      
      The call to "schedule_work()" in rtc_initialize_alarm() happens too
      early, and can cause oopses at bootup
      
      Neil Brown explains why we do it:
      
        "If you set an alarm in the future, then shutdown and boot again after
         that time, then you will end up with a timer_queue node which is in
         the past.
      
         When this happens the queue gets stuck.  That entry-in-the-past won't
         get removed until and interrupt happens and an interrupt won't happen
         because the RTC only triggers an interrupt when the alarm is "now".
      
         So you'll find that e.g.  "hwclock" will always tell you that
         'select' timed out.
      
         So we force the interrupt work to happen at the start just in case."
      
      and has a patch that convert it to do things in-process rather than with
      the worker thread, but right now it's too late to play around with this,
      so we just revert the patch that caused problems for now.
      Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
      Requested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Requested-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f423fc62
    • S
      [CIFS] default ntlmv2 for cifs mount delayed to 3.3 · 225de11e
      Steve French 提交于
      Turned out the ntlmv2 (default security authentication)
      upgrade was harder to test than expected, and we ran
      out of time to test against Apple and a few other servers
      that we wanted to.  Delay upgrade of default security
      from ntlm to ntlmv2 (on mount) to 3.3.  Still works
      fine to specify it explicitly via "sec=ntlmv2" so this
      should be fine.
      Acked-by: NJeff Layton <jlayton@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      225de11e
    • J
      cifs: fix bad buffer length check in coalesce_t2 · 497728e1
      Jeff Layton 提交于
      The current check looks to see if the RFC1002 length is larger than
      CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
      that by MAX_CIFS_HDR_SIZE.
      
      This bug has been around for a long time, but the fact that we used to
      cap the clients MaxBufferSize at the same level as the server tended
      to paper over it. Commit c974befa changed that however and caused this
      bug to bite in more cases.
      Reported-and-Tested-by: NKonstantinos Skarlatos <k.skarlatos@gmail.com>
      Tested-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      497728e1
    • L
      Revert "rtc: Disable the alarm in the hardware" · 157e8bf8
      Linus Torvalds 提交于
      This reverts commit c0afabd3.
      
      It causes failures on Toshiba laptops - instead of disabling the alarm,
      it actually seems to enable it on the affected laptops, resulting in
      (for example) the laptop powering on automatically five minutes after
      shutdown.
      
      There's a patch for it that appears to work for at least some people,
      but it's too late to play around with this, so revert for now and try
      again in the next merge window.
      
      See for example
      
      	http://bugs.debian.org/652869
      
      Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra)
      Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500)
      Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830)
      Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr>  (Toshiba Portege R830)
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Requested-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: stable@kernel.org  # for the versions that applied this
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      157e8bf8
    • M
      hung_task: fix false positive during vfork · f9fab10b
      Mandeep Singh Baines 提交于
      vfork parent uninterruptibly and unkillably waits for its child to
      exec/exit. This wait is of unbounded length. Ignore such waits
      in the hung_task detector.
      Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
      Reported-by: NSasha Levin <levinsasha928@gmail.com>
      LKML-Reference: <1325344394.28904.43.camel@lappy>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9fab10b
    • J
      security: Fix security_old_inode_init_security() when CONFIG_SECURITY is not set · 30e05324
      Jan Kara 提交于
      Commit 1e39f384 ("evm: fix build problems") makes the stub version
      of security_old_inode_init_security() return 0 when CONFIG_SECURITY is
      not set.
      
      But that makes callers such as reiserfs_security_init() assume that
      security_old_inode_init_security() has set name, value, and len
      arguments properly - but security_old_inode_init_security() left them
      uninitialized which then results in interesting failures.
      
      Revert security_old_inode_init_security() to the old behavior of
      returning EOPNOTSUPP since both callers (reiserfs and ocfs2) handle this
      just fine.
      
      [ Also fixed the S_PRIVATE(inode) case of the actual non-stub
        security_old_inode_init_security() function to return EOPNOTSUPP
        for the same reason, as pointed out by Mimi Zohar.
      
        It got incorrectly changed to match the new function in commit
        fb88c2b6: "evm: fix security/security_old_init_security return
        code".   - Linus ]
      Reported-by: NJorge Bastos <mysql.jorge@decimal.pt>
      Acked-by: NJames Morris <jmorris@namei.org>
      Acked-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30e05324
    • O
      fix CAN MAINTAINERS SCM tree type · 405cc273
      Oliver Hartkopp 提交于
      As pointed out by Joe Perches the SCM tree type was missing in my patch.
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      
      CC: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
      CC: Urs Thuermann <urs.thuermann@volkswagen.de>
      CC: Wolfgang Grandegger <wg@grandegger.com>
      CC: Marc Kleine-Budde <mkl@pengutronix.de>
      CC: linux-can@vger.kernel.org
      405cc273
    • A
      mwifiex: fix crash during simultaneous scan and connect · b015dbc0
      Amitkumar Karwar 提交于
      If 'iw connect' command is fired when driver is already busy in
      serving 'iw scan' command, ssid specific scan operation for connect
      is skipped. In this case cmd wait queue handler gets called with no
      command in queue (i.e. adapter->cmd_queued = NULL).
      
      This patch adds a NULL check in mwifiex_wait_queue_complete()
      routine to fix crash observed during simultaneous scan and assoc
      operations.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b015dbc0
    • G
      b43: fix regression in PIO case · 09009512
      Guennadi Liakhovetski 提交于
      This patch fixes the regression, introduced by
      
      commit 17030f48
      From: Rafał Miłecki <zajec5@gmail.com>
      Date: Thu, 11 Aug 2011 17:16:27 +0200
      Subject: [PATCH] b43: support new RX header, noticed to be used in 598.314+ fw
      
      in PIO case.
      Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      09009512
    • M
      ath9k: Fix kernel panic in AR2427 in AP mode · b25bfda3
      Mohammed Shafi Shajakhan 提交于
      don't do aggregation related stuff for 'AP mode client power save
      handling' if aggregation is not enabled in the driver, otherwise it
      will lead to panic because those data structures won't be never
      intialized in 'ath_tx_node_init' if aggregation is disabled
      
      	EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k]
      	EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000
      	ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c
      	DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      	Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860
      	task.ti=f40dc000)
      	Stack:
      	0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac
      	f40e1cb0 f8186741
      	f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001
      	c0b4ba43 00000000
      	0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac
      	f2a30000 00010020
      	Call Trace:
      	[<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k]
      	[<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k]
      	[<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350
      	[mac80211]
      	[<c018dc75>] ? __module_address+0x95/0xb0
      	[<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211]
      	[<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0
      	[mac80211]
      	[<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211]
      	[<c018440b>] ? trace_hardirqs_on+0xb/0x10
      	[<c056936e>] ? skb_queue_tail+0x3e/0x50
      	[<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750
      	[mac80211]
      	[<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211]
      	[<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211]
      	[<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k]
      	[<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
      	[<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
      	[<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k]
      	[<c0151b7e>] tasklet_action+0xbe/0x180
      
      Cc: stable@kernel.org
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Reported-by: NAshwin Mendonca <ashwinloyal@gmail.com>
      Tested-by: NAshwin Mendonca <ashwinloyal@gmail.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b25bfda3